Even webgpu makes performance portability hard and keeps the user manually setting barriers etc. We could use a modern but yet higher level api.
Shameless plug: We have a graph based approach which automates all intermediate resource allocations and scheduling. I am hoping we can opensource it or something similar as it separates definitions of the algorithms nicely from how they are scheduled in the end (async compute on amd and so forth are all automatic). We also have backend implementations for all the major modern apis.
I believe the plug is misplaced here, since you misunderstood the article contents. WebGPU does not have the user manually setting barriers or allocating memory.
The current version of the webgpu doesn't talk much about synchronization primitives https://github.com/gpuweb/gpuweb (same that can be reached from the original post), the little it reveals is DX12 style running fences that are used in multi-adapter system.
If they do not have explicit barriers within a device then it has to do state tracking, bringing the CPU overhead back into the level of OpenGL and making multithreaded command recording almost useless. The original WebGPU (now WebMetal) proposal did have explicit barriers.
We also have explicit resource creation available as when you create a texture you just want a texture. No fancy stuff there.
-I thought the original article was just gfx-rs supporting the WebGPU as a backend.- EDIT: I did misunderstand it. It's wgpu-rs that's a new api. The WebGPU in between had me confused.
EDIT2: I misunderstood it doubly. It is WebGPU implementation on top of gfx-rs. So points about WebGPU stand.
I do agree that the information on what WebGPU does and what not isn't clearly available. It's all in the IDL ([1]), where you may notice no API for explicit barriers. We are working on more readable documentation/specification.
> If they do not have explicit barriers within a device then it has to do state tracking, bringing the CPU overhead back into the level of OpenGL and making multithreaded command recording almost useless.
I don't believe this to be correct. We have the state tracking implemented in wgpu-rs, and it's designed from day one to support multi-threaded command recording. Implementation-wise, every command buffer knows which resources it expects in which states, and what states they end up with. When it's submitted, the WebGPU queue inserts necessary transitions into those input states, and it tracks the current state of all resources.
Yes, there is some CPU overhead there for sure, but it's not yet clear how significant it is. Keep in mind that WebGPU has to validate the states, which is roughly the same complexity as deriving those states in the first place, hence our decision to do so.
> WebGPU also has the usual way of allocating memory.
Not directly. Currently, users can create resources and not care about their lifetimes. This is contrary to Vulkan/D3D12 memory allocation with transient resources, which is what your frame graphy library helps with.
Thanks for pointing out the IDL. That tells a lot more about the API.
It's good to know that the state tracker is bit more refined than what is required for something like OpenGL.
>Yes, there is some CPU overhead there for sure, but it's not yet clear how significant it is. Keep in mind that WebGPU has to validate the states, which is roughly the same complexity as deriving those states in the first place, hence our decision to do so.
One of the benefits of prebuilding the frame as a graph ahead of time is that one can do vast majority of the validation ahead of time, thus making the heavy operation be explicit for the user. Also the validation happens only once, instead of every frame.
Just like when you bind pipeline you do not have to again validate that all of the shaders etc are valid. Just that it's valid for this renderpass etc. In OpenGL one has to validate the graphics pipeline state after every change to it, whereas in WebGPU it's enough to validate most of it on creation. Similar thing applies to building the state transitions ahead of time.
> Currently, users can create resources and not care about their lifetimes.
For some reason I assumed that if there is a createTexture there ought to be destroyTexture for it. But indeed there is not. I have a few questions pertaining to this.
How does it know I'm not going to need a texture anymore? If it has to keep the data valid for eternity it will at the very least have to store it to ram or disk because it never knows if I'm going to submit a command that references it again.
This sounds to me that some applications where lots of assets are streamed in will explode in memory usage. Or then the user has to do manual pooling, which can be even more difficult and bug prone.
The assumption is to rely on GC and if a resource is not reachable in JS (or in existing bindings), then it can't be submitted again, so it can safely be cleaned up. There is also an explicit GPUTexture.destroy() method if you want to free up the GPU memory immediately.
Shameless plug: We have a graph based approach which automates all intermediate resource allocations and scheduling. I am hoping we can opensource it or something similar as it separates definitions of the algorithms nicely from how they are scheduled in the end (async compute on amd and so forth are all automatic). We also have backend implementations for all the major modern apis.