Implications of WebGPU adoption for Trame #482
-
|
Hey Trame community! I've started following the adoption of WebGPU recently and it got me thinking about its implications for Trame apps. As I understand it, the adoption of WebGPU, when coupled with the porting of C++ vtk to WebAssembly, could bridge the gap between the performance and functionality of web rendering and native desktop applications. How would this change be reflected in Trame? Could we expect the capabilities of local/client-side rendering to become comparable to those of remote/server rendering? Would local/client-side rendering use the Web Assembly C++ port or continue to use vtk.js? If the latter, would vtk.js use the WebAssembly C++ port under the hood? |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 1 reply
-
|
We are in the process of getting a VTK/wasm module for trame to better handle local rendering. Once VTK/C++ gets updated to use WebGPU (instead of OpenGL), that given module will have the full power of WebGPU. Also, we are thinking of using that same infrastructure under vtk.js to deal with the rendering layer. But that part is more long term than the current one with trame. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome! So it sounds like, in the near-term, Trame local rendering would improve through use of the VTK/wasm module instead of vtk.js, and independent of Trame, vtk.js would see similar improvements but on a longer timescale? And what does this mean for serializers? In the case that the geometry is computed by the server, serialized, and sent to the client for local rendering, I've seen lack of vtk.js serializers pop up as a problem (e.g., here, here, or here). Would these issues become a moot point/irrelevant with the use of VTK/wasm + WebGPU? Or would currently missing serializers still need to be constructed (perhaps with the transition providing motivation to do so?) |
Beta Was this translation helpful? Give feedback.
-
|
Using the wasm path with trame should eliminate all the serialization/capabilities issues. In the beginning, we will encounter small glitches that need to be fixed at the VTK/C++ level. But once those are handled, we should achieve full parity. WebGPU will happen later, but the code usage will remain unchanged after the transition. |
Beta Was this translation helpful? Give feedback.
-
|
Gotcha, thanks for the insight @jourdain! So it seems that porting the vtk C++ to wasm and adopting WebGPU will operate on two separate timelines. Do you have a sense of what those are (e.g., a couple months or a couple years?) |
Beta Was this translation helpful? Give feedback.
-
|
wasm: a couple of weeks |
Beta Was this translation helpful? Give feedback.
-
|
Sweet, thanks @jourdain! Looking forward to following this :) |
Beta Was this translation helpful? Give feedback.
We are in the process of getting a VTK/wasm module for trame to better handle local rendering. Once VTK/C++ gets updated to use WebGPU (instead of OpenGL), that given module will have the full power of WebGPU.
Also, we are thinking of using that same infrastructure under vtk.js to deal with the rendering layer. But that part is more long term than the current one with trame.