Porting WebGL Shaders to WebGPU

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Build time-series-based applications quickly and at scale.
  • SonarQube - Static code analysis for 29 languages.
  • SaaSHub - Software Alternatives and Reviews
  • gpuweb

    Where the GPU for the Web work happens!

    I don't think this is really a fair interpretation, but I'll say I am definitely biased in favor of WebGPU[2].

    WebGPU is focused on landing 1.0 currently, so yes, more features are not on the immediate roadmap.

    But they've been considering/investigating adding support for this before mesh shaders in DX12 were even finalized[0] so it's not like there is some "we cannot / will not expose that functionality" mandate going on here. Despite its name, WebGPU is actually pretty much a 1:1 mapping of what is commonly available across APIs.

    Separately, AMD doesn't support mesh shaders in Vulkan either, in fact Vulkan doesn't at all outside of a Nvidia extension from what I understand - and it sounds like there are some concerns from Khronos about whether they even map to all GPU architectures in a reasonable way at all.[1]

    If you want to argue "but by dropping to the level of DX12, Vulkan, Metal, etc. I can use some very specific new features" that's totally true, but you can do that with WebGPU native too: after all, Dawn and other WebGPU implementations are just abstractions over those 3 APIs. One can just as easily hop into their code and add your own extension to make use of Mesh shaders in DX12, I can say that at least Dawn's codebase is set up to allow for such extensions from what I've seen.

    [0] https://github.com/gpuweb/gpuweb/issues/445

    [1] https://github.com/KhronosGroup/Vulkan-Docs/issues/1423#issu...

    [2] https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...

  • naga

    Universal shader translation in Rust

    > What guarantees do you have it won't happen again?

    Apple was pretty clear about their intent not to ship WebGL2, and they did the opposite for WebGPU so it's not gonna be the same story. Of course, I can't be 100% sure that Apple won't change their mind or anything, but there is no reason to believe they'll do so.

    > Even if Apple had done it on time, it was a 2012 hardware API for 2017 hardware

    Most games released in 2017 had to support hardware from 2012 anyway. Even AAA games released this year support GPU released in 2012[0]! For non AAA games, targeting a 5-years old API is probably the newest you can afford. We're not talking about bringing the bleeding edge GPU tech to the web (it won't, it's never standardised anyway, like Mesh shaders you talked about). The goal is to provide modern standardized tech to developers, and it does it in a portable way, which makes it even more affordable.

    > Intel had two failed attempts to bring compute into the browser.

    So what ?

    > Yes it is a very bad thing, when Vulkan can keep using GLSL and HLSL, while DX12 happily will use any HLSL from the API history, and Metal can use proper C++14 shaders.

    Vulkan uses SPIR-V, not HSL or GLSL. Translation tooling exist, but it also exists for WGSL -> SPIR-V[1]

    Each platform has its own shading language, will this one be better than the other, I don't know but I don't think it's gonna be worse either.

    > WGSL is web politics as usual.

    Not really. See this summary[2] from a Mozilla gfx engineer:

    [0]: https://support.activision.com/black-ops-cold-war/articles/m...

    [1]: https://github.com/gfx-rs/naga

    [2]: https://kvark.github.io/webgpu-debate/SPIR-V.component.html

  • InfluxDB

    Build time-series-based applications quickly and at scale.. InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises.

  • noclip.website

    A digital museum of video game levels

    I took a very different approach for porting my WebGPU shaders over: I have far too many shaders to port (sometimes pretty massive ones! [0]), so I used Naga [1] at to runtime-translate my GLSL shaders to WGSL. I had to get involved a bit upstream to fix quite a few different bugs in the implementation, but once I got it working I was really happy with the result. It's quite fast, it compiles to a pretty light-weight WebAssembly module, and it works surprisingly well.

    [0] https://github.com/magcius/noclip.website/blob/e15f8045cf262...

  • naga-include-poc

    Cool project, there is also someone working on making wgsl and glsl together: https://github.com/scoopr/naga-include-poc

  • wgsl-cheat-sheet

    Cheat sheet for WGSL syntax for developers coming from GLSL.

    Good article, I was looking for a resource like this when I was experimenting with WGSL. I ended up writing a short cheat sheet that might be useful to others here: https://github.com/paulgb/wgsl-cheat-sheet

  • WASI

    WebAssembly System Interface

  • webgpu-wgsl-hello-triangle

    An example of how to render a triangle with WebGPU using WebGPU Shading Language - the "Hello world!" of computer graphics.

  • SonarQube

    Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.

  • Vulkan-Docs

    The Vulkan API Specification and related tools

    I don't think this is really a fair interpretation, but I'll say I am definitely biased in favor of WebGPU[2].

    WebGPU is focused on landing 1.0 currently, so yes, more features are not on the immediate roadmap.

    But they've been considering/investigating adding support for this before mesh shaders in DX12 were even finalized[0] so it's not like there is some "we cannot / will not expose that functionality" mandate going on here. Despite its name, WebGPU is actually pretty much a 1:1 mapping of what is commonly available across APIs.

    Separately, AMD doesn't support mesh shaders in Vulkan either, in fact Vulkan doesn't at all outside of a Nvidia extension from what I understand - and it sounds like there are some concerns from Khronos about whether they even map to all GPU architectures in a reasonable way at all.[1]

    If you want to argue "but by dropping to the level of DX12, Vulkan, Metal, etc. I can use some very specific new features" that's totally true, but you can do that with WebGPU native too: after all, Dawn and other WebGPU implementations are just abstractions over those 3 APIs. One can just as easily hop into their code and add your own extension to make use of Mesh shaders in DX12, I can say that at least Dawn's codebase is set up to allow for such extensions from what I've seen.

    [0] https://github.com/gpuweb/gpuweb/issues/445

    [1] https://github.com/KhronosGroup/Vulkan-Docs/issues/1423#issu...

    [2] https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts