Back in the day I did a similar error with wrapping C graphic libraries directly 1:1 with improved C++ bindings, until I realised it was more ergonomic to think in higher level C++ abstractions, and exposed those concepts instead, fully hiding the underlying unsafe C APIs.
Re:What's Next for WebGPU
by ladyanita22 on Sunday November 24, 2024 @09:37AM
(#42228139)
I'm interested in reading more. Where will you continue this?
Yes. I think I'm beginning to see what's gone wrong with the Rust crates. It's an architectural problem. Vulcano and WGPU try to create a Rust safety perimeter at an API that's basically a wrapper around Vulkan. This may be the wrong boundary for that safety perimeter.
Moving buffer allocation inside the safety perimeter may eliminate a level of locking and checking. Bindless really brings this out, because somebody has to keep the descriptor table and buffer allocation in sync. The GPU depends on that. So that has safety implications.
If this problem is partitioned differently, the locking problems for concurrent GPU content updating may become simpler. Right now, both Vulcano and WGPU force more serialization than Vulkan itself requires. The rendering thread is too often stalled on a lock waiting for some content updating operation that should not interfere with rendering.
Too much detail for this forum. I'll continue this elsewhere. This has been useful.