Comment by ladyanita22
8 months ago
I thought WGPU only supported WebGPU, and then there were translation libraries (akin to Proton) to run WebGPU over Vulkan.
Does it directly, internally, support Vulkan instead of on-the-fly translation from WebGPU to VK?
WGPU (https://wgpu.rs/) is one of currently three implementations of the WebGPU specification (the other two being Google's Dawn library used in Chrome, and the implementation in WebKit used in Safari).
The main purpose of WebGPU is to specify a 3D API over the common subset of Metal/D3D12/Vulkan features (e.g. doing an 'on-the-fly translation' of WebGPU API calls to Metal/D3D12/Vulkan API calls, very similar to how (a part of) Proton does an on-the-fly translation of the various D3D API versions to Vulkan.
You're describing the WebGPU spec and its different implementations.
OP claimed WGPU had native support for VK, DX and others. But as far as I know, WGPU just supports WebGPU being translated on the fly to those other backends, with the obvious performance hit. If I'm wrong, I'd be interested to know, as this would make WGPU a more interesting choice for many if, in reality, the code was native instead of translation.
Edit: https://docs.rs/wgpu/latest/wgpu/#backends it seems they indeed support native code in almost every backend?
I don't understand the question...
Those three WebGPU implementation libraries are compiled to native code (they are written in Rust or C/C++), and at least WGPU and Dawn are usable as native libraries outside the browser in regular native apps that want to use WebGPU as a cross-platform 3D API.
Yet still, those native libraries do a runtime translation of WebGPU API calls to DX/Vk/Metal API calls (and also a runtime translation of either WGSL or SPIRV to the respective 3D backend API shading languages) - in that sense, quite similar to what Proton does, just for a different 'frontend API'.
1 reply →
Within the constrains of the browser sandbox and 10 year old hardware, which is when its design started.
I think it's more about low-end mobile GPUs which WebGPU needs to support too (which is also the main reason why Vulkan is such a mess). The feature gap between the low- and high-end is bigger than ever before and will most likely continue to grow.
10 replies →