4 ms·
WebGPU on native is the best bet to bring back the times where you could reasonably write once and run everywhere. See also - http://kvark.github.io/web/gpu/nat
by kvark 5y ago
WebGPU on native is the best bet to bring back the times where you could reasonably write once and run everywhere. See also - http://kvark.github.io/web/gpu/native/2020/05/03/point-of-webgpu-native.html http://kvark.github.io/web/gpu/native/2020/05/03/point-of-we...
- slmjkdbtl 5y agoThanks for the article it's a great write up! Do you mean it's possible in the future venders will ship WebGPU drivers built in their product (couldn't find any evidence on that yet) or it's the best option for the interface of a translation layer like wgpu? Right now wgpu is already pretty solid as a translation layer, but direct driver support will be so good. (Also thanks for your works on Rust graphics related stuff! They benefit me a lot)
- kvark 5y agoI don't expect any driver support for this in the nearest future. The promise of WebGPU on native is not in wgpu library quality, although it's a part of the equation. The promise is in a well-thought specification (of WebGPU API) and the standardized API headers with multiple implementations. This matches best practices from Khronos.
- pjmlp 5y agoI consider that is best served by middleware engines taking the best advantage of each platform main API. WebGPU still isn't at the same comfort level as the frameworks provided by platform owners for their APIs.