▲ | pjmlp 4 days ago | |||||||||||||||||||||||||
Outside of the browser the answer is middleware. WGPU has to decide, either stay compatible with WebGPU, and thus be constrained by the design of a Web 3D API, or embrace native code and diverge from WebGPU. | ||||||||||||||||||||||||||
▲ | slimsag 4 days ago | parent [-] | |||||||||||||||||||||||||
This is the right answer^ But even more, the level at which WebGPU exists (not too high level, not too low level) necessitates that if a native API graphics abstraction sticks with the WebGPU's API design and only 'extends' it, you actually end up with three totally different ways to use the API: * The one with your native 'extensions' -> your app will only run natively and never in the browser unless you implement two different WebGPU rendering backends. Also won't run on Chromebook-type devices that only have GLES-era hardware. * The WebGPU browser API -> your app will run in the browser, but not on GLES-era hardware. Perish in the verbosity of not having bindless support. * The new 'compatability' mode in WebGPU -> your app runs everywhere, but perish in the verbosity of not having bindless, suffer without reversed-z buffers because the underlying API doesn't support it. And if you want your app to run in all three as best as possible, you need to write three different webgpu backends for your app, effectively, as if they are different APIs and shading languages. | ||||||||||||||||||||||||||
|