Is there any kind of roadmap or update on supporting either macOS Metal or Vulkan in VTK? Time is marching on and at some point sooner rather that later those of us trying to support macOS will have a decision to make regarding either walking away from macOS support or walking away from VTK.
I am actively developing a vulkan backend at least to the point where if apple removes OpenGL we can pretty quickly get something going for VTK. It will use MoltenVK to drive Metal. It exists and passes some tests. It is currently missing an absurd number of features but it is what I am working on right now and I plan to continue fleshing it out for at least a couple more weeks if not more. My current goal is risk mitigation so that should something happen we have a reasonable head start on addressing it.
It would be nice sometime in the next few months to start preparing/examinging what changes would be required in PV to use vulkan. Right now PV directly interfaces with some OpenGL classes and that would need to be rersolved.
@ken-martin Thanks for the update. It is nice knowing that some work is going on in the background. I can’t predict the future and I have no “insiders” information at Apple but my guess is that macOS 10.16 that comes out this fall (assumes that Apple sticks to this schedule) would still have OpenGL but I’m fairly sure 10.17 that would come out in fall of 2021 would have OpenGL removed.
I know this thread is quite old, but I just wanted to know if you believe these Vulkan-related plans in VTK (I think this is the best way to go as well) will be compatible with the Java wrapping for VTK?
Maybe through the lwjgl / lwjglx / lwjgl3-awt libraries?
Cross-platform support for usage of VTK from a Java application has improved a lot lately in VTK, and it would be great if these integration possibilities will be kept for the future as well.
Any feedback on this will be appreciated.
Regards,
Where can I find updates on the MoltenVK work in VTK? I found the kitware vulkan fork here. It looks like the work didn’t relate to iOS just yet, but is it enough to be able to determine if it’s a/the best path forward for VTK to run on future Macs?
I see the Jogl-based work that @Martin3d has mentioned here. We’ve been experiencing issues with Coretto OpenJDK 8 and Jogl 2.4 on iOS 11. There are fixes in OpenJDK 11 for Swing/AWT for Mac by implementing a Metal-based pipeline, which helps with our 2D graphics, but which don’t help for our 3D-based applications.
Any thoughts on the future, and what we should work toward?
Do you mean issues on iOS 11 or macOS 11? I presume the later. If you have feedbacks about JOGL 2.4 on macOS, I would be interested to know more about it. Do not hesitate to answer on the JOGL forum thread discussing this.
Our group hasn’t gotten our hands on a Mac built on M1 processor yet. After we do that, we’ll upgrade to JDK 17 where the graphics pipeline should support Metal and the new Apple Silicon architecture is supported, then try our Jogl-based applications. We’re already using Jogl 2.4 in our cross-platform apps.
Happy to follow up with more information.
Something you may find interesting if you intend to go toward recent JDKs : I started evaluating the Panama project (a.k.a JEP-412), which simplifies access to native libs. It may be an interesting direction to either replace or complement JOGL (the main contributor left, hence my implication on upgrading JOGL for recent macOS). Look at the issue list to have a better idea of the open topics.
I think this tooling could be interesting to have Vulkan accessible from Java. Same for Metal that could probably be accessed directly without passing through MoltenVK.
Yes, I haven’t tried the JEP package yet, because it looked like most of our JNI-based native libraries will continue to work (for now?). Re-writing our implementations of Jogl and VTK will probably be required anyway for Mac, so it will be interesting if that “incubated” JEP project gets better support in the meantime. Seeing your examples will definitely help when we decide to move over our implementations.
Switching to Metal or Vulkan (with JEP or some other Java native access) would be probably more work in the long run, considering how much we’d have to pay attention to details that would otherwise be abstracted (hence why we have used VTK in the past).
The vulkan/webgpu work in C++ is still on hold for now. It is progressing in vtk.js and that architecture will be adopted here (either in vulkan or webgpu the basic architecture is the same) We’ve been focusing on adding OpenXR support lately which is in reasonable shape now. But this is definitely still on our todo list.
The vulkan/webgpu work in C++ is still on hold for now.
As it’s been almost a year, I thought I’d just give a friendly ping… Any news on Vulkan support? (Or more generally addressing the issue of Apple considering OpenGL deprecated?)
Happily, OpenGL is at least still present and working reasonably on macOS 13 Ventura (released 2 days ago).
One thing coming back to my mind : in the case OpenGL get deprecated on macOS, there is an option to make it work using Vulkan+MoltenGL+MESA+Zink (!).
I actually was not able to achieve this myself but others did. The post may be useful to contiinue discussing issues on this point.
VTK just got an experimental WebGPU-C++ polydata mapper . Currently, it works in webassembly on Chrome 113 developer build and on Linux using Vulkan. Work is ongoing to bring more functionality. The plan is to use Dawn-C++ to enable Metal rendering on Apple, Vulkan on linux, android and DirectX on windows. Metal is Apple’s answer to Vulkan that’s not as scary as Vulkan, yet not as fragile as OpenGL.