6 ms·

> A text based language would be easier for beginners (since they wouldn't need to install a separate shader compiler) and would avoid sites that need dynamic s

> A text based language would be easier for beginners (since they wouldn't need to install a separate shader compiler) and would avoid sites that need dynamic shaders having to download and run a shader compiler in the browser. That is more or less the official rationale, but it's pretty clear that the real reason is that Apple is organizationally opposed to SPIR-V (and Khronos generally). This is a tough needle to thread, so I'm glad forward progress is being made.

throwaway34241 7y ago
Regardless of Apple’s motivations those still are real benefits, I think at least one major WebGL framework uses dynamic shader generation and was looking at going the bundled-shader-compiler route. Hopefully this approach cuts back on the projects that find it necessary to do that and encourages faster adoption from WebGL.
- kevingadd 7y ago
  If you're willing to do dynamic shader generation as text, you can generate shader bytecode. The real question is which of the two options produces more performant shaders and faster compile times, since naively-generated shader bytecode isn't being optimized like your text is. If you care about compile times text-based can be a lot worse (this matters for the Dolphin emulator, for example)
  - throwaway34241 7y ago
    That’s true, even if the semantics are the same (and parsing time isn’t a big factor) the assumptions for what optimizations have been applied to bytecode might be different. I remember seeing in one of the meeting notes that they didn’t expect browsers to end up making assumptions about the optimization level of the SPIR-V they ingest anyway but I don’t remember the specific rationale for that. There’s of course also the time for the SPIR-V -> gpu native step. It would be nice if they could just cache that and skip the whole process most of the time.
  - kvark 7y ago
    That is correct, in theory, but there is a large gap between theory and practice. How practical would it be for, say Three.JS to generate shader bytecode? Would it need to depend on a sophisticated WASM module that allows to build such bytecode? Who is going to build that? Google has spent a lot of effort trying to answer these questions, and they got close, but in the end the text-based solution prevailed. In part, because it was easy to agree on for all parties.
    - Jasper_ 7y ago
      Do you not expect GLSL -> WGSL compilers in actual practice? I don't think anybody using Three.JS today would switch to writing WGSL unless they could also ingest it on WebGL.
      - kvark 7y ago
        In one of the futures, our shader translation infrastructure will support GLSL input and produce WGSL output :)
jfkebwjsbx 7y ago
Indeed. A text-based language makes no sense in 2020. WASM already took the approach of going binary-first.
- antoineMoPa 7y ago
  If you want live-tweakable or generated webgpu shaders, which will be useful in many applications text based is much better as no complex tooling is required.
  - rubber_duck 7y ago
    Useful to what applications ? Even writing modern JS requires a compiler stack, adding a shading language would be a matter of writing a webpack loader.
    - antoineMoPa 7y ago
      As an example, ShaderToy (and ShaderGif which I built) compile shaders directly in the browser.
      - jfkebwjsbx 7y ago
        As they have already told you, shaders being in binary or text form is orthogonal to making a tool like ShaderToy. However, binary form is way more compact for transmission, storage and performance. Almost nobody will use the text form except developers.
        mantap 7y ago
        The transmission/storage size of shaders isn't important. Textures and 3D models dominate in any non trivial project. Kind of like dieting by trimming your toenails.
        jacobolus 7y ago
xenadu02 7y ago
I strongly favor sticking to DRM-free text-based formats for the web. I remember learning a lot just from looking at the HTML and JS sources from web pages. It's been a great boon for the web up until now. Besides lots of apps already ship shaders as text. They get dynamically compiled and cached, just like JS does. Being text-based hasn't stopped JS from greatly improving performance. Khronos sat on their hands for years and only moved after Apple shipped Metal and AMD dumped Mantle in their laps (I'll note that Metal came first). SPIR-V is not the be-all end-all of shader programming. Personally I don't believe we should accept some lowest-common-denominator that puts the future of GPU development in the hands of an organization with the track record Khronos has wrt managing OpenGL. That goes double for the future of WebGPU. However I recognize those are just personal opinions and reasonable people may disagree. To those offering opinions here: If you've never written a renderer or shader can I suggest you write a toy project using both then see if you still have the same opinion?
- pcwalton 7y ago
  The problem with the view-source argument is that source is often minified these days, so you need a decompiler of some sort to go from the bits on the wire to something human-readable no matter what. A pretty-printer can sometimes be simpler than an IR decompiler, but often not really.
  - tylerchilds 7y ago
    I purposefully don't minify the source on my personal website, so people can still learn from inspecting it, if they'd like to.

throwaway34241 7y ago

Regardless of Apple’s motivations those still are real benefits, I think at least one major WebGL framework uses dynamic shader generation and was looking at going the bundled-shader-compiler route. Hopefully this approach cuts back on the projects that find it necessary to do that and encourages faster adoption from WebGL.

kevingadd 7y ago
If you're willing to do dynamic shader generation as text, you can generate shader bytecode. The real question is which of the two options produces more performant shaders and faster compile times, since naively-generated shader bytecode isn't being optimized like your text is. If you care about compile times text-based can be a lot worse (this matters for the Dolphin emulator, for example)
- throwaway34241 7y ago
  That’s true, even if the semantics are the same (and parsing time isn’t a big factor) the assumptions for what optimizations have been applied to bytecode might be different. I remember seeing in one of the meeting notes that they didn’t expect browsers to end up making assumptions about the optimization level of the SPIR-V they ingest anyway but I don’t remember the specific rationale for that. There’s of course also the time for the SPIR-V -> gpu native step. It would be nice if they could just cache that and skip the whole process most of the time.
- kvark 7y ago
  That is correct, in theory, but there is a large gap between theory and practice. How practical would it be for, say Three.JS to generate shader bytecode? Would it need to depend on a sophisticated WASM module that allows to build such bytecode? Who is going to build that? Google has spent a lot of effort trying to answer these questions, and they got close, but in the end the text-based solution prevailed. In part, because it was easy to agree on for all parties.
  - Jasper_ 7y ago
    Do you not expect GLSL -> WGSL compilers in actual practice? I don't think anybody using Three.JS today would switch to writing WGSL unless they could also ingest it on WebGL.
    - kvark 7y ago
      In one of the futures, our shader translation infrastructure will support GLSL input and produce WGSL output :)

jfkebwjsbx 7y ago

Indeed. A text-based language makes no sense in 2020. WASM already took the approach of going binary-first.

antoineMoPa 7y ago
If you want live-tweakable or generated webgpu shaders, which will be useful in many applications text based is much better as no complex tooling is required.
- rubber_duck 7y ago
  Useful to what applications ? Even writing modern JS requires a compiler stack, adding a shading language would be a matter of writing a webpack loader.
  - antoineMoPa 7y ago
    As an example, ShaderToy (and ShaderGif which I built) compile shaders directly in the browser.
    - jfkebwjsbx 7y ago
      As they have already told you, shaders being in binary or text form is orthogonal to making a tool like ShaderToy. However, binary form is way more compact for transmission, storage and performance. Almost nobody will use the text form except developers.
      - mantap 7y ago
        The transmission/storage size of shaders isn't important. Textures and 3D models dominate in any non trivial project. Kind of like dieting by trimming your toenails.
        jacobolus 7y ago

xenadu02 7y ago

I strongly favor sticking to DRM-free text-based formats for the web. I remember learning a lot just from looking at the HTML and JS sources from web pages. It's been a great boon for the web up until now. Besides lots of apps already ship shaders as text. They get dynamically compiled and cached, just like JS does. Being text-based hasn't stopped JS from greatly improving performance. Khronos sat on their hands for years and only moved after Apple shipped Metal and AMD dumped Mantle in their laps (I'll note that Metal came first). SPIR-V is not the be-all end-all of shader programming. Personally I don't believe we should accept some lowest-common-denominator that puts the future of GPU development in the hands of an organization with the track record Khronos has wrt managing OpenGL. That goes double for the future of WebGPU. However I recognize those are just personal opinions and reasonable people may disagree. To those offering opinions here: If you've never written a renderer or shader can I suggest you write a toy project using both then see if you still have the same opinion?

pcwalton 7y ago
The problem with the view-source argument is that source is often minified these days, so you need a decompiler of some sort to go from the bits on the wire to something human-readable no matter what. A pretty-printer can sometimes be simpler than an IR decompiler, but often not really.
- tylerchilds 7y ago
  I purposefully don't minify the source on my personal website, so people can still learn from inspecting it, if they'd like to.