7 ms·

What improvements does WebGPU bring vs WebGL for things like Potree?

by kam 1y ago

m-schuetz 1y ago
Compute shaders, which can draw points faster than the native rendering pipeline. Although I have to admit that WebGPU implements things so poorly and restrictive, that this benefit ends up being fairly small. Storage buffers, which come along with compute shaders, are still fantastic from a dev convenience point of view since it allows implementing vertex pulling, which is much nicer to work with than vertex buffers. For gaussian splatting, WebGPU is great since it allows implementing sorting via compute shaders. WebGL-based implementations sort on the CPU, which means "correct" front-to-back blending lags behind for a few frames. But yeah, when you ask like that, it would have been much better if they had simply added compute shaders to WebGL, because other than that there really is no point in WebGPU.
- pjmlp 1y ago
  They did, Intel had the majority of the work done, and then Google sabotaged the effort, because WebGPU was right around the corner. https://registry.khronos.org/webgl/specs/latest/2.0-compute/ https://registry.khronos.org/webgl/specs/latest/2.0-compute/ https://github.com/9ballsyndrome/WebGL_Compute_shader/issues/9 https://github.com/9ballsyndrome/WebGL_Compute_shader/issues...
flohofwoe 1y ago
Access to slightly more recent GPU features (e.g. WebGL2 is stuck on a feature set that was mainstream ca. 2008, while WebGPU is on a feature set that was mainstream ca 2015-ish).
- m-schuetz 1y ago
  All of these new features could have easily be added to WebGL. There was no need for creating a fundamentally different API just for compute shaders.
  - flohofwoe 1y ago
    The GL programming only feels 'natural' if you've been following GL development closely since the late 1990s and learned to accept all the design compromises for sake of backward compatibility. If you come from other 3D APIs and never touched GL before it's one "WTF were they thinking" after another (just look at VAOs as an example of a really poorly designed GL feature). While I would have designed a few things differently in WebGPU (especially around the binding model), it's still a much better API than WebGL2 from every angle. The limited feature set of WebGPU is mostly to blame on Vulkan 1.0 drivers on Android devices I guess, but there's no realistic way to design a web 3D API and ignore shitty Android phones unfortunately.
    - m-schuetz 1y ago
      It's not about feeling natural - I fully agree that OpenGL is a terrible and outdated API. It's about the complete overengengineered and pointless complexity in Vulkan-like APIs and WebGPU. Render Passes are entirely pointless complexity that should not exist. It's even optional in Vulkan nowadays, but still mandatory in WebGPU. Similarly static binding groups are entirely pointless, now I've got to cache thousands of vertex and storage buffers. In Vulkan you can nowadays modify those, but not in WebGPU. Wish I could batch them buffers in a single one so I dont need to create thousands of bind groups, but that's also made needlessly cumbersome in WebGPU due to the requirement to use staging buffers. And since buffer sizes are fairly limited, I can't just create one that fits all, so I have to create multiple buffes anyway, might as well have a separate buffer for all nodes. Virtual/Sparse buffers would be helpful in single-buffer designs by growing those as much as needed, but of course they also dont exist in WebGPU. The one thing that WebGPU is doing better is that it does implicit syncing by default. The problem is, it provides no options for explicit syncing. I mainly software-rasterize everything in Cuda nowadays, which makes the complexity of graphics apis appear insane. Cuda allows you to get things done simple and easily, but it still has all the functionaility to make things fast and powerful. The important part is that the latter is optinal, so you can get things done quickly, and still make them fast. In cuda, allocating a buffer and filling it with data is a simple cuMemAlloc and cuMemcpy. When calling a shader/kernel, I dont need bindings and descriptors, I simply pass a pointer to the data. Why would I need that anyway, the shader/kernel knows all about the data, the host doesnt need to know.

What improvements does WebGPU bring vs WebGL for things like Potree?

by kam 1y ago

What improvements does WebGPU bring vs WebGL for things like Potree?

Compute shaders, which can draw points faster than the native rendering pipeline. Although I have to admit that WebGPU implements things so poorly and restrictive, that this benefit ends up being fairly small. Storage buffers, which come along with compute shaders, are still fantastic from a dev convenience point of view since it allows implementing vertex pulling, which is much nicer to work with than vertex buffers. For gaussian splatting, WebGPU is great since it allows implementing sorting via compute shaders. WebGL-based implementations sort on the CPU, which means "correct" front-to-back blending lags behind for a few frames. But yeah, when you ask like that, it would have been much better if they had simply added compute shaders to WebGL, because other than that there really is no point in WebGPU.

pjmlp 1y ago
They did, Intel had the majority of the work done, and then Google sabotaged the effort, because WebGPU was right around the corner. https://registry.khronos.org/webgl/specs/latest/2.0-compute/ https://registry.khronos.org/webgl/specs/latest/2.0-compute/ https://github.com/9ballsyndrome/WebGL_Compute_shader/issues/9 https://github.com/9ballsyndrome/WebGL_Compute_shader/issues...

flohofwoe 1y ago

Access to slightly more recent GPU features (e.g. WebGL2 is stuck on a feature set that was mainstream ca. 2008, while WebGPU is on a feature set that was mainstream ca 2015-ish).

m-schuetz 1y ago
All of these new features could have easily be added to WebGL. There was no need for creating a fundamentally different API just for compute shaders.
- flohofwoe 1y ago
  The GL programming only feels 'natural' if you've been following GL development closely since the late 1990s and learned to accept all the design compromises for sake of backward compatibility. If you come from other 3D APIs and never touched GL before it's one "WTF were they thinking" after another (just look at VAOs as an example of a really poorly designed GL feature). While I would have designed a few things differently in WebGPU (especially around the binding model), it's still a much better API than WebGL2 from every angle. The limited feature set of WebGPU is mostly to blame on Vulkan 1.0 drivers on Android devices I guess, but there's no realistic way to design a web 3D API and ignore shitty Android phones unfortunately.
  - m-schuetz 1y ago
    It's not about feeling natural - I fully agree that OpenGL is a terrible and outdated API. It's about the complete overengengineered and pointless complexity in Vulkan-like APIs and WebGPU. Render Passes are entirely pointless complexity that should not exist. It's even optional in Vulkan nowadays, but still mandatory in WebGPU. Similarly static binding groups are entirely pointless, now I've got to cache thousands of vertex and storage buffers. In Vulkan you can nowadays modify those, but not in WebGPU. Wish I could batch them buffers in a single one so I dont need to create thousands of bind groups, but that's also made needlessly cumbersome in WebGPU due to the requirement to use staging buffers. And since buffer sizes are fairly limited, I can't just create one that fits all, so I have to create multiple buffes anyway, might as well have a separate buffer for all nodes. Virtual/Sparse buffers would be helpful in single-buffer designs by growing those as much as needed, but of course they also dont exist in WebGPU. The one thing that WebGPU is doing better is that it does implicit syncing by default. The problem is, it provides no options for explicit syncing. I mainly software-rasterize everything in Cuda nowadays, which makes the complexity of graphics apis appear insane. Cuda allows you to get things done simple and easily, but it still has all the functionaility to make things fast and powerful. The important part is that the latter is optinal, so you can get things done quickly, and still make them fast. In cuda, allocating a buffer and filling it with data is a simple cuMemAlloc and cuMemcpy. When calling a shader/kernel, I dont need bindings and descriptors, I simply pass a pointer to the data. Why would I need that anyway, the shader/kernel knows all about the data, the host doesnt need to know.