[2020] WGSL is terrible!

[misyltoad]

You're making the exact same mistakes that OpenGL did -- having a source-level language (text) be your main shader input; and we all know how well that turned out.
There's a reason that Vulkan and DirectX use some form of bytecode representation for shaders.

There is no such thing as "trivially convertible to/from SPIR-V" when it's source-level like this because you actually need to write full on compiler for it (ie. parsing, tokenizing etc). It's feels like it's just the W3C making another terrible standard that's impossible for anyone without hundreds of developers (ie. Apple, Google, Mozilla) to implement in any rational way.

In fact, while I am here why are the W3C making a shading language, when you couldn't even be trusted with HTML?

The current spec as it stands is also inconsistent and randomly flips between GLSL, WGSL and HLSL semantics: eg. the float4 here

Why do some of these have ;, some have , and some nothing at the end of their declarations.

The language looks genuinely terrible already:

I can read SPIR-V just fine by eye, but what the hell is a continuing block? You're just making up random keywords no-one has heard before! Not to mention there's also unless and regardless whatever the hell they do. :v

Why is a simple loop so bloody complicated? This isn't how anyone thinks when they write a shader.

How can you look at this and expect anybody to write code for it?
Serious question: are you actually expecting anyone to write this by hand?
If you're not, then please for the love of god just use a bytecode representation. If you are, then please make it not so completely unusable for literally any purpose.

I agree that GLSL is kinda crap and we desperately need a new source level language but this really isn't it. Everything is needlessly verbose for a shading language, vec4<f32> is going to get old very fast, and overall it just makes things unreadable, given there's going to be <> cluttering up everywhere (C++ templates all over for everything is... ew).

It's just like someone saw Rust, thought it was cool, then tried to make some representation of SPIR-V using Rust syntax...

What problems does WGSL solve that SPIR-V doesn't? None. You're just wasting everyone's time by making them implement some stupid WGSL -> SPIR-V translator. Just take in SPIR-V on your end, and validate it if you have to and limit to some subset. Don't take in some high level source language that nobody is going to ever write in.

If you want to make a new source-level language, then that's fine too! GLSL sucks.
But nobody in their right mind is gonna write whatever the hell this is.

[litherum]

It's feels like it's just the W3C making another terrible standard

you couldn't even be trusted with HTML

The language looks genuinely terrible

what the hell

You're just making up random keywords

whatever the hell they do

Why is a simple loop so bloody complicated?

How can you look at this and expect anybody to write code for it?

are you actually expecting anyone to write this by hand?

for the love of god

GLSL is kinda crap

It's just like someone saw Rust, thought it was cool

What problems does WGSL solve that SPIR-V doesn't? None. You're just wasting everyone's time

stupid

GLSL sucks.

But nobody in their right mind is gonna write whatever the hell this is.

I believe these violate the W3C's Code of Ethics and Professional Conduct.

Please act professionally. I am sure the group would be willing to have a constructive conversation about these issues if you edited the post to change its language and tone. This group is interested in specific and actionable issues.

@litherum Weaponizing the Code of Conduct to attack the OP also violates the code of conduct, don't use the existence of mean words to dismiss their arguments.

[TheSpydog]

The OP may be incendiary in their critique, but I completely agree with the points presented. In particular:

Serious question: are you actually expecting anyone to write this by hand?
If you're not, then please just use a bytecode representation. If you are, then please make it not so completely unusable for literally any purpose.

As I understand it, WGSL is a compromise between a textual language and SPIR-V. Unfortunately I think it takes the worst of both worlds. The whole point of SPIR-V is to be an unambiguous and portable shader representation that can be transformed into other languages or directly ingested by drivers. It's not primarily intended to be written/read by humans. As a result, a language that maps 1:1 with SPIR-V is not going to be ideal for the average shader programmer. This is clear in the proposed syntax, which contains constructs I think most devs would find awkward, foreign, and unintuitive. This "high level" language is still designed for the computer, not the programmer.

However, even if the syntax was immediately intuitive, any new textual language still throws away the most valuable property of SPIR-V: it already exists. It's already in toolchains. It's a known quantity. It has uses outside of WebGPU. Every shader cross-compiler worth its salt already supports bi-directional compilation to/from SPIRV. Why introduce another mandatory conversion with WGSL <-> SPIRV?

I imagine for most cross-platform devs (especially those who are not targeting web exclusively), a typical shader's journey will look like GLSL/HLSL/MSL -> SPIRV -> WGSL -> SPIRV -> GLSL/HLSL/MSL -> native code. Every piece of that already exists, except for WGSL, which by its definition cannot offer anything that SPIRV can't already. So why the middle-man? I haven't seen a sufficient explanation for this, even in the FAQ.

Honestly I think much of the backlash to this decision could be mitigated if SPIRV was still an option. I'm not a web browser engineer, so I don't claim to know the intricacies involved, but it makes so much sense to me that any use for a language with a stated goal of being "trivially convertible to SPIR-V" should have the opportunity to be substituted with, ya know, SPIR-V.

I've heard a couple arguments against allowing SPIR-V, but I don't think either of them hold much water:

1. Two different shading languages would fragment the ecosystem. (Even though they're supposedly bijective? And how many people would write WGSL directly anyway, at least in its current state?)
2. It would double the attack surface. (How? Afaik the browser is going to have to parse/compile a SPIRV equivalent language anyway. Couldn't parts of the implementation be shared between WGSL and SPIRV?)

All that to say... I'm just not convinced that WGSL makes sense for the WebGPU platform. Which is a huge bummer, since I was really looking forward to the new API, both for web and native. I strongly urge the working group to reconsider this decision, or at least clearly explain the benefits of this approach beyond "you can still write shaders by hand".

[misyltoad]

My main gripe is that there is so much unnecessary duplicated effort, and in a way that makes things super redundant.

Vulkan implementations translate from SPIR-V -> [some ir ->] native code without going back to some source-level language. So for for Vulkan implementations of WebGPU, the path would look like: GLSL/HLSL/MSL -> SPIRV -> WGSL -> SPIRV -> [some ir ->] native code... Fun round trips!

In the case of D3D12 implementations, the path would probably look like: GLSL/HLSL/MSL -> SPIRV -> WGSL -> SPIRV -> DXIL -> [some ir ->] native code. There are already existing implementations of SPIRV->DXIL, (and I guess you could do to DXIL directly but that would be a lot of wasted effort that someone would need to maintain, browsers are feature creepy enough already...)
I would hope browser vendors don't end up doing WGSL -> HLSL in some form anyway... That would be very naïve. 🐸

If the problem is having a nice textual representation for Javascript blobs, then that already exists in the form of spirv-dis. The parser/assembler for that stuff already exists too! 😛

In my opinion, there is no reason just to use some limited subset of SPIR-V other than needlessly over-complicating things on purpose.

And yeah, the argument about an attack vector is just complete garbage. Writing a new source language to remove that is a logical fallacy. Just add some incredibly primitive and basic validation of what already exists.

[nicebyte]

i think it would be nice if the reasons for wgsl existence were spelled out explicitly in the spec. as it stands, it is just not very clear why an implementation couldn't ingest spir-v directly given the stated goals. that would clear up many of the questions people are having :)

[Triang3l]

I agree about the weird syntax details (though I still would not like ++i to be located before values it can depend on in the code — this would contradict the whole idea), but to me the concept of WGSL sounds like the best thing that could happen to shading languages so far, as it combines the core features of a high-level textual language for humans and SSA intermediate representations for compilers.

A stand-alone, endian- and encoding-independent textual representation that you don't need external tools to comfortably write is a common concept on the web. You have JavaScript, HTML, CSS being exactly that, the only difference here is that, unlike in JavaScript's case, compiler's needs are also taken into account this time.

WGSL isn't any fundamentally more complicated to compile than SPIR-V or DXIL — parsing is a trivial step, what WGSL removes is complex control flow and dependency analysis. WGSL to some other SSA IR is still a more or less single-pass operation with respect to multiple statements.

This does make control flow a bit unusual for those who are used to writing in C-like languages (but everything makes sense if you've ever written SPIR-V by yourself), however, unlike in SPIR-V assembly, you still have structured blocks to some extent, but most importantly mathematical formulas are still mathematical formulas — you don't have to split them into barely readable stacks of mads and rcps.

Being close to IR and still readable also makes WGSL pretty much the very rare case of a shading language actually debuggable by design — mutability being more of an exception and const being the default choice (this applies to writing in C, C++ and JavaScript as well), plus always reducible, straightforward control flow, allows not only the compiler, but your vision to easily, in a single pass, trace the path that resulted in some intermediate value (and it will consist of actually readable formulas rather than flat assembly instructions), this also opens up potential for node-graph-like material debugging with intermediate values visualized as colors.

There will not be any issues with tools as you can easily plug a WGSL backend into anything that can emit SPIR-V or DXIL — such as DXC which can already emit both, the only things that would need to be done is expanding phi into a variable and possibly slight control flow loop reformatting, but mostly it will map 1:1.

In short, you aren't losing anything with WGSL, but you're getting a stand-alone (including writing and debugging) language that is as easy to compile as SPIR-V. It's still pretty much like writing regular code, but with const used for everything that's not going to be changed and with more explicit control flow.

What WGSL really needs is a fast reference parser with a simple API that implementations could use to avoid all the crazy bugs that were omnipresent in GLSL compilers of mobile GPU drivers, such as interpreting uniform struct arrays as unions or something weird like that on Adreno 320, then it won't be any less reliable than SPIR-V.

[Pauan]

@Triang3l parsing is a trivial step

I don't have an opinion on this issue, however parsing is not a trivial step: the primary reason WebAssembly was invented was because parse times for asm.js were too slow. Bytecode parsing is orders of magnitude faster, which has a big impact.

And the size savings are important too, since the user has to download the code before it can run, so every byte matters.

And a properly designed binary format can support streaming compilation (like WebAssembly does), whereas text generally can't be streamed like that (unless it's carefully designed and restricted).

In fact, bytecodes are so important for the web that there is even a proposal for a bytecode format for JS.

[Aransentin]

it is just not very clear why an implementation couldn't ingest spir-v directly

The reason WebGPU can't use Khronos' SPIR-V directly is because Apple has a private legal dispute with Khronos that they haven't disclosed the details of. The other reasons for WGSL's existence seem to be post-hoc rationalizations.

[Kangz]

@litherum is correct in that this issue violates the W3C code of conduct, in particular this point:

Communicate constructively and avoid demeaning or insulting behavior or language.

I'll close this issue to avoid further derailing but feel free to create new ones focused on a piece of constructive feedback. Feedback I was able to extract from this issue is the following:

• The current spec has examples that aren't valid WGSL. (feel free to open a PR!)
• The loop construct is alien and WGSL should have more familiar loop constructs. I opened a PR for it.
• The angle-bracket syntax to create composite type is more verbose than their GLSL and HLSL counterparts.
• WGSL will add another step to the shader compilation pipeline of existing projects.
• Consider adding SPIR-V as another option.