Currently we use VTK for a Qt6 based cross platform visualization application. As we all know OpenGL on MacOS is deprecated and stuck at version 4.1. At some point in the future, this version will not be good enough for the needs of the VTK community/project and VTK will need to move past version 4.1 of OpenGL. At that point any new VTK development would not be supported on MacOS. We can hang on to the last supported version of VTK for MacOS for a while after that but at some point, that will fall apart.
If VTK on Vulkan is not a thing, and I didn’t come up with VTK on Metal in my searches what are the plans for a cross platform desktop application that uses VTK for MacOS? WebGPU (currently) would be fairly difficult to use from a desktop C++ application although there is lots of time to try and make needed updates to allow that to happen.
Can you elaborate on this, why do you think it would be difficult? Most VTK users are building applications using VTK’s abstract lights-cameras-actor model, not interfacing with the actual graphics subsystem, so what’s under the hood is of lesser concern.
Right now, WebGPU is looking promising because it is supported on both web and desktop, serving as common API for stuff under the hood like Vulkan, Metal, etc. I am not a rendering guy, but the folks that are are certainly interested in your concerns.
We have similar concerns and strive to use the most widely supported graphics stack.
Using WebGPU doesn’t change anything drastically for a VTK application as it will still use the same mappers, actors, lights, cameras, renderer, window and interactor.
From our research, WebGPU desktop seems promising and we have initiated efforts in that direction. Technical details here - [1]. Linux has experimental support right now, we expect the same level of support in mac and windows later this year.
The VTK::RenderingWebGPU module builds against Dawn[2] - Google’s implementation of WebGPU API in C++. Dawn uses Vulkan on Linux, DirectX on Windows and Metal on macos. Consequently, VTK will indirectly benefit from the best API on each platform.
Remember once again that, VTK abstracts away the webgpu API, so, at a high level, nothing would really change for applications using VTK. To support applications with custom OpenGL shaders, VTK could use tools like glslang to transpile shaders into hlsl/msl or directly into spir-v bytecode at runtime.
@will.schroeder
The name does not help, WebGPU leads one to believe that I would need to switch to JavaScript and QML and/or go to an Electron based application. Looking a bit deeper into “WebGPU” seems to indicate that there is movement to implement some C/C++ wrappers around WebGPU to make this yet-another-cross-platform graphics API.
We use Qt 6 as our GUI software stack and I have found this New graphics integration in Qt WebEngine 6.6 and even 6.5. I have asked on the Qt interest list for some comments from the Qt Company about any plans for WebGPU integration.
There is a lot of noise to cut through for someone who does not deal with this everyday. Basic searches on your favorite search engine give links that all discuss trying out WebGPU in your favorite browser. So maybe this is just a marketing thing with "Web"GPU.
I am just trying to make sure that there is a future for VTK in our desktop application. I would imagine that ParaView is going to face the exact same issues. (Qt + VTK on the desktop).
The name does not help, WebGPU leads one to believe that I would need to switch to JavaScript and QML and/or go to an Electron based application. Looking a bit deeper into “WebGPU” seems to indicate that there is movement to implement some C/C++ wrappers around WebGPU to make this yet-another-cross-platform graphics API.
Please don’t view them as wrappers. It is easier to understand when these are viewed as implementation of a specification in a language.
Yes, all this is difficult to understand for the regular VTK developer. Being in the weeds having implemented the VTK-Dawn C++ integration myself, let me attempt to clarify some things.
Firstly, we have to understand that WebGPU is a specification, not a library.
The specification is an official document [1] that is written collaboratively by Google, Mozilla, Apple and many collaborators from the graphics industry (hence the name “Web”). It was initially called “NXT”
The big three implement the specification in C++/Rust to enable WebGPU in their respective browsers. To oversimplify it, the browsers forward javascript calls into those C++/Rust methods.
Now it’s easier to understand that there is no real webgpu library in javascript. In fact there is no concept of a language in webgpu at all. With that out of the way, Dawn is Google’s pure C++ desktop implementation of WebGPU with zero JavaScript.
I am just trying to make sure that there is a future for VTK in our desktop application. I would imagine that ParaView is going to face the exact same issues. (Qt + VTK on the desktop).
We also do not like to ask our desktop users to switch over to electron based apps. Changing ParaView to electron would require so much refactoring that we simply cannot do it. ParaView would use Dawn through VTK and ensure the correct hooks are setup to interface with the right backend in Qt RHI [2]
@Michael_Jackson You’re right - the name webGPU is a misnomer at this point. Though there is history behind it as @jaswantp explained.
From a future VTK user perspective, here’s what you would need to know:
When VTK moves over to WebGPU, VTK applications would not need to introduce major changes to adapt to the changed VTK rendering intrinsics.
Mappers in VTK would switch over to using webgpu to forward graphics calls to platform-specific graphics API (Vulkan on linux, Direct3D on Windows and Metal on macOS). This will all be opaque to the VTK consumer applications.
VTK would (or should) introduce abstractions over webgpu api so that advanced rendering pipeline users can switch their shader customizations over to webgpu shaders
There will be a few changes, like the ability to switch webgpu implementations, etc.
Of course, this is a major undertaking and will be done in a piecemeal fashion as was done for the OpenGL2 transition a few years back. Hope that helps.