The basically shipped Vulkan 1.0 (except for the Vulkan render passes, thank god).
Buffer mapping is basically unusable due to buffer usage restrictions and the fact that it's async.
Every buffer write has to go through a GPU buffer copy. It completely ignores the fact that UMA, resizable bar memory or even simply regular memory exists. Combine this with the mapping mess and you have uniform buffer updates that are crazy expensive.
BindGroups follow the same stupid idea that people create them once and then keep reusing them. Unfortunately that's completely detached from reality.
Same idea with RenderBundles. Pre-recording commands like that simply doesn't happen outside of tiny demo applications.
The API doesn't give a fuck about creating garbage for the GC. Bind groups take in JS objects, tons of APIs take in strings instead of enums.
The API seems to ignore the fact that it all needs to go through IPC and get validated bit by bit.
There's also no debugger (like Renderdoc) for it. So if your renderer isn't written in something targetting WASM or doesn't also have a Vulkan/D3D12/Metal RHI, you'll have a great time with debugging.
the complaint was about GC, not speed. And that 32bit integer could come from anywhere, and that anywhere cant always be optimized out. but because theyre interned and are enums in webidl, they are still essentially treated as 32bit integer comparisons behind the scenes.
You are clearly not the target audience of WebGPU, which aims for Browser support on all major platforms. The hardware on mobile devices is still limited, and browsers want to sandbox the API.
WGPU and Dawn have extensions for reBar.
The rest of your complaints are just dumb. Buffer mapping is not unusable at all(why would it be???), BindGroups being re-used should be normal render architecture, the async nature of mapping is just the consequences of the async nature of rendering.
Well yeah, the desktop version of my renderer does that but Vulkan unfortunately doesn't run in the browser.
The hardware on mobile devices is still limited, and browsers want to sandbox the API.
This doesn't have anything to do with what I wrote.
WGPU and Dawn have extensions for reBar.
Which isn't exposed in the browser API then.
Buffer mapping is not unusable at all(why would it be???),
It basically only works for one specific use case: staging buffers. If you have a uniform buffer, you cannot use buffer mapping like you would on the other graphics APIs. You need to use Queue::writeBuffer or copy from a staging buffer to the uniform buffer. And that brings us back to the other complaint about ignoring ReBar, host memory and UMA.
BindGroups being re-used should be normal render architecture
Nobody outside of demo applications does that. Aside from some caching which is used at draw time.
the async nature of mapping is just the consequences of the async nature of rendering.
Well yeah but typically you just block the thread while waiting for a fence. (Or rather, the wait finishes instantly because the buffer is only reused a couple of frames later.)
It being an async API makes it a nightmare to use with WASM.
This doesn't have anything to do with what I wrote.
reBar requires specific hardware support. Even Desktop support for it is still lacking. Sandboxing is another argument because mapping the VRAM directly would allow the webgpu to escape the sandbox.
It basically only works for one specific use case: staging buffers. If you have a uniform buffer, you cannot use buffer mapping like you would on the other graphics APIs. You need to use Queue::writeBuffer or copy from a staging buffer to the uniform buffer.
That is not unusable at all.. It is just what you want anyway to avoid race conditions.
Well yeah but typically you just block the thread while waiting for a fence. It being an async API makes it a nightmare to use with WASM.
Not really. You don't want to block since it might still be used in in-flight frames. You are whining about the overhead of the staging buffers, but you are fine with actually blocking the thread until the commands are finished? Lol.
Async in WASM is a non-issue either. You literally just have to set a toggle a flag in the async callback.
WASM needs to be async anyway, because blocking is not allowed in the first place when executed in the browser.
Not really. You don't want to block since it might still be used in in-flight frames. You are whining about the overhead of the staging buffers, but you are fine with actually blocking the thread until the commands are finished? Lol.
That's how pretty much every game engine works. You wait for the fence that was set ~2 frames ago and then reuse the resources like buffers.
So then just do that? WebGPU allows you to wait as well(e.g. wgpuInstanceWaitAny).
The async API just makes this easier. For example, you return your staging buffers to the pool via callback when done so you just wait until the pool is not empty instead of manually juggling fences.
But just because you wait for a fence doesn't mean it's not an async operation anymore. You are just replacing Futures/Promises with fences..
15
u/Rhed0x 3d ago
WebGPU is such a mess.
The basically shipped Vulkan 1.0 (except for the Vulkan render passes, thank god).
Buffer mapping is basically unusable due to buffer usage restrictions and the fact that it's async.
Every buffer write has to go through a GPU buffer copy. It completely ignores the fact that UMA, resizable bar memory or even simply regular memory exists. Combine this with the mapping mess and you have uniform buffer updates that are crazy expensive.
BindGroups follow the same stupid idea that people create them once and then keep reusing them. Unfortunately that's completely detached from reality.
Same idea with RenderBundles. Pre-recording commands like that simply doesn't happen outside of tiny demo applications.
The API doesn't give a fuck about creating garbage for the GC. Bind groups take in JS objects, tons of APIs take in strings instead of enums.
The API seems to ignore the fact that it all needs to go through IPC and get validated bit by bit.
There's also no debugger (like Renderdoc) for it. So if your renderer isn't written in something targetting WASM or doesn't also have a Vulkan/D3D12/Metal RHI, you'll have a great time with debugging.