VTK WebGPU Roadmap

Development
1

Disclaimer: Please do not confuse the “web” with JavaScript. The goal is to use pure C webgpu header/implementations on desktop AND support web applications through webassembly :slight_smile:

Last year, we added experimental webgpu backend in VTK for rendering polydata. You can read more about it here- https://www.kitware.com/vtk-webgpu-on-the-desktop/. The primary goal was to speed up rendering of really large number of actors and it was actually 1.6x faster than VTK’s OpenGL rendering subsystem.

In this post, I want to summarize the current status of webgpu desktop in VTK C++ and provide a listing of the action items planned for the rest of the year.

In VTK,

  • The code lives in the VTK::RenderingWebGPU module.
  • This module provides factory overrides for vtkRenderWindow, vtkRenderer, vtkActor, vtkPolyDataMapper, etc.
  • An up to date guide of how to build VTK with Dawn is documented here VTK::RenderingWebGPU - VTK documentation.
  • It works on linux using X11 for window system and in a web browser with webassembly.
  • There is no CI for webgpu.
Action Item Status
Use webgpu-native headers To be done in 2024
Dynamically load webgpu implementation at runtime To be done in 2024
WSI - x11 + vtkHardwareWindow To be done in 2024
WSI - macos + vtkHardwareWindow To be done in 2024
WSI - windows + vtkHardwareWindow To be done in 2024
WSI - html5 (emscripten) + vtkHardwareWindow To be done in 2024
WSI - wayland + vtkHardwareWindow Future work
WSI - ios + vtkHardwareWindow Future work
WSI - android + vtkHardwareWindow Future work
WSI - wasi (wasi-webgpu) + vtkHardwareWindow Future work
Shader customizations To be done in 2024
Compute shaders To be done in 2024
Volume rendering Looking for funding
Speed up frustum culling with compute shader To be done in 2024
Speed up polygon tessellation with compute shader To be done in 2024
CI infrastructure with established webgpu implementations To be done in 2024

**: WSI=Window System Integration
**: @sankhesh took a stab at using webgpu-native headers and improving WSI support in vtk/vtk!10239
**: wasi= WebAssembly System Interface is a specification which tells how wasm can be used outside a web browser. wasi-webgpu is being designed here - GitHub - WebAssembly/wasi-webgpu

These items are tracked in the master issue here - vtk/vtk#19315

Cc: @tom.clabault @lgivord @Thomas_Galland @sankhesh @cory.quammen @Francois_Mazen

7 Likes
2

Spectacular roadmap!

If I could suggest something, that would be to add CI as soon as possible before adding new features.

2 Likes
3

add CI as soon as possible before adding new features.

I agree that we have to prioritize this.

4

Is supporting wayland on linux a difficult challenge as several linux distros default to wayland? Would the user need to revert to x11 to be able to test this?

5

I do not know much about wayland protocol from a developer POV to comment. Any wayland sample applications? definitely should be future work imo.

1 Like
6

Sound good, I see webGPU efforts as a future proof initiative for VTK with opengl being a legacy API (+ MacOS abandoned opengl), in a few years x11 may be considered a legacy protocol but will undoubtable still be on option for linux users who need it unlike opengl on MacOS, I know this is apples and oranges to even compare these.

7

I have just starting working with WebGPU, WebGL and wasm. In VTK we have vtkSMPTools. Would it be possible to create a new threading backend with posix-threads and populate this with web-workers?

I know this is not WebGPU but extremely relevant now that we speed up the rendering.

8

Could you shed some light on why volume rendering is singled out as “looking for funding”? Is it something much more difficult? Or not important for existing paying customers?

What is the price tag (rough estimate)?

Are some fixes or improvements planned as part of this effort? It could help with fundraising if it would make multi-volume rendering usable, RTX would be utilized, etc.

9

Unimportant to our existing paying customers right now. We have submitted proposals regarding webgpu and volume rendering. Cc: @sankhesh and @jcfr

10

Closing out 2024, are you able to provide an update on the roadmap going into 2025 ?

1 Like
11

@Nicholas_Yue

Thanks for your interest. Yes, we have been able to check off some items, thanks to one of our existing customers who was primarily interested in using webgpu backend in VTK.wasm applications.

Additionally, we are in the process of budgeting for wasm, and webgpu in VTK. We plan to implement most of the remaining items in 2025 :slight_smile:

This time around, we will be focusing more on the toolchain and integrating with various operating systems. Here’s the updated roadmap:

Action Item Status
Use webgpu-native headers To be done in 2025
Dynamically load webgpu implementation at runtime To be done in 2025
WSI - x11 + vtkHardwareWindow To be done in 2025
WSI - macos + vtkHardwareWindow To be done in 2025
WSI - windows + vtkHardwareWindow To be done in 2025
WSI - html5 (emscripten) + vtkHardwareWindow To be done in 2025
WSI - wayland + vtkHardwareWindow To be done in 2025
WSI - ios + vtkHardwareWindow To be done in 2025
WSI - android + vtkHardwareWindow To be done in 2025
WSI - wasi (wasi-webgpu) + vtkHardwareWindow To be done in 2025
Shader customizations To be done in 2025
Compute shaders Done in 2024
Volume rendering To be done in 2025
Speed up frustum culling with compute shader Done in 2024
Speed up polygon tessellation with compute shader Done in 2024
CI infrastructure with established webgpu implementations Done in 2024

Blogs:
webgpu-compute-api-in-vtk
webgpu-occlusion-culling-in-vtk

3 Likes