Not the person you're replying to, but a start would be to use an existing proven shader format like SPIRV or DXIL instead of making up an entirely new shader ecosystem in order to satisfy the whims of a single browser vendor and waste everyone's time.
SPIR-V already has a lot of collaboration, and will provide natural synergy with non Web use cases, since it's the standard bytecode format for shaders there already. So collaboration argument goes for SPIR-V here.
Human readability of the shader shipped from the page is a different argument, and it can have some merit, but the same could be argued against using WebAssembly for instance which is not very human readable in comparison with JavaScript. I don't think it's a strong argument against using it.
By that standard, everything with respect to a shader ISA for the web is "new and immature." The point is finding a suitable common ground for all vendors to agree on working on. Not everyone going every which way to work on uncoordinated efforts.
It seems like there would be alternate ways to do online shader generation than concatenating strings and compiling if there were a well-formed binary standard. Maybe it is the easiest conceptually, but I don't see that as being a performance target in that case.
Edit: Also seems like they are leaning pretty heavily into Babylon.js. I don't think a standard should be developed that closely with any one specific application or framework.
I do agree that a text based format is better in many cases. A byte code format would suck for debugging. People want to type their shaders directly into a browser window and have compilation happen in less than a frame. Shader compilation needs to be fast enough that it takes less than a frame because people do have things like colour pickers in their in-browser shader editor where you can drag the value around and it changes the text. To emulate this without browser support would require a lot of work.
But that text based format should be GLSL because that's what everybody's shaders are already written in for WebGL and obviously there will be a transition period where both WebGL and WebGPU will have to be supported (which is easy since most people use a library such as Babylon or Three).
Having a text based language that is not GLSL is pointless IMO. You have the drawbacks of both a bytecode language (need to ship a compiler with the page to compile GLSL into WSL) and textual formats.
As an outsider the most logical option is to support both GLSL and SPIR-V.
It already made sense to have a SPIRV- and SPIRVCross-based shader pipeline in cross-platform engines with WebGL support though (because you'd want to author shaders in one shading language only, and then translate them to various target languages, like some desktop GLSL version, then separate versions for GLES2/WebGL and GLES3/WebGL2, and finally HLSL and MSL, WGSL is just another output option in such an asset pipeline).
Is there really such a great need to make the lowest level shader API more accessible to beginners? You can always build things on top that make a low-level API more friendly, but you can never build something below the lowest available level (short of inventing a new standard). What kind of beginners are these that want to do low-level shader programming, but without any tooling? Don't web programmers already accept the use of heavyweight build tools even for their plan old ordinary Javascript?
My enthusiasm for seeing yet another GPU language is very restricted. I simply cannot see the rational arguments in favour of this design. We were so close to having a standard IR for this stuff.
This I definitely agree with. The standard should focus on a safe byte code representation, similar to SPIRV. The actual shader language should be an offline tool or JS/WASM module and shouldn't matter much as long as it can compile to the standardized byte code format.
this is kind of BS, all it takes is one cheap shared hosted server collecting shaders from users(upload every time you check for new version/once a day), you would build 95% complete list in couple of months.
If the alternative is to manually maintain 2..10 (or so) versions of each shader for different shading languages, GLSL versions or shader variations manually, then code generation or transpilation from a common source is a pretty good compromise.
Interesting, can you really create complex enough shaders for everyday game usage? I am not a game developer, so I really have no idea. Just wondering what you imagine the most popular shaders will be.
SPIR-V with full web safety rules and translation to native shader formats is not really simpler to implement than WSL with those same properties. People make these claims but the code doesn’t best that out.
There’s also a good chance that in the end the shader processing will be in a common library like ANGLE.
With GLAL the issues were much more about the drivers consuming a textual language than about the browser consuming a textual language.
The answer to shader snippets in the SPIR-V world would be linking. I don't think that's well developed in the ecosystem if at all, but it's a perfectly natural extension.
A web-based interface for building and managing shaders for 3D apps and renderers. Features would include a node-based shader builder, plugins for the various 3D packages (Maya, Max, Houdini, XSI, etc), suppport for the various shading languages (RSL, VEX, mental ray, Cg, etc), and user groups and permissions. Think sourceforge for 3D artists, small studios without the ability to roll their own management solutions would like this.
Workflow is like this: user creates shader using node editor (think Maya's Hypershade, but Ajaxified...), then sets permissions for the shader. Any user with permission to use the shader can see it from the plugin for his app of choice on his machine and use it. The user sets the renderer that he wants to use, the shader is compiled on the server and sent down the pipe to the user. That way, source code is kept in the hands of the people who created it. Scene renders.
I would love to build something like this, but it requires a lot more CS knowledge than I have. So if you think it's cool, roll with it and invite me to the private beta.
reply