How closely does wgpu track changes to the WGSL spec?

[Twisol]

I'm currently going through the learn-wgpu guide, and I noticed that the WGSL [[attribute]] syntax accepted by wgpu doesn't match the @attribute syntax in the current draft. This spec change seems to go back to January 19 and this PR.

Of course, if WGSL is a moving target, it's totally fair that wgpu doesn't match it in lockstep! But the wgpu README doesn't provide a dated WGSL spec (in fact, it links to the latest editor's draft), so it's hard for a newcomer like me to judge the gap between what wgpu supports and what the current WGSL spec provides. I'd like to be able to reference the WGSL spec to understand what functionality I can use; but I'm unable to tell whether wgpu itself supports the specified functionality.

I also recognize that the latest version of wgpu (0.12.0) was released before the attributes change above, so it would be unreasonable to expect it to support that particular change. Even so, the published README for this version also hotlinks to the Editor's Draft, so it remains both easy to be misled and hard to know what is actually supported.

So, my concrete questions:

• Does wgpu commit to tracking changes to the WGSL spec on any particular timespan? (I'm satisfied with "no"!)
• Does wgpu implement any one dated WGSL specification, or perhaps a Frankenstein mix of several?
• Is it possible to say what, exactly, the gaps are between the WGSL supported by wgpu and any moderately recent WGSL specification?
• Based on the above, could the wgpu README be updated to qualify the WGSL support against the reality of a moving target?

[cwfitzgerald]

Thanks for asking such a detailed question!

Does wgpu commit to tracking changes to the WGSL spec on any particular timespan? (I'm satisfied with "no"!)

No :) we just try our best to keep up

Does wgpu implement any one dated WGSL specification, or perhaps a Frankenstein mix of several?

We always work towards latest, so we end up with a Frankenstein mix.

Is it possible to say what, exactly, the gaps are between the WGSL supported by wgpu and any moderately recent WGSL specification?

That might be a reasonable way to do it, keep a list of wgsl changes and show when we implemented it.

Based on the above, could the wgpu README be updated to qualify the WGSL support against the reality of a moving target?

Sure, PR's accepted :)

Targeting a moving spec is fun because the more it changes the less time you have for documenting the changes, but the less it changes the more time to document the changes. WGSL in particular had a period of moving quite quickly followed by a lot of small scale changes, so the 0.12 -> current jump is particularly glaring.

Fwiw, I don't think versions WGSL specs exist really, unless there's some magic url I don't know about, there's just the current spec and the slightly more out of date copy hosted by w3.

[Twisol]

Thanks for taking the time to answer my questions! 😃

No :) we just try our best to keep up

We always work towards latest, so we end up with a Frankenstein mix.

Totally understandable, and about what I was expecting to be honest 😉

Fwiw, I don't think versions WGSL specs exist really, unless there's some magic url I don't know about, there's just the current spec and the slightly more out of date copy hosted by w3.

There's a big ol' master list of dated drafts that I used to hunt down exactly when the attribute syntax change occurred. Since wgpu implements a Frankenstein mix, there probably isn't a good single draft to link to -- but it does seem possible in theory (if time-consuming!) to pick out a draft and document the gap between wgpu and that specification.

[jimblandy]

wgpu-core is used by Firefox's WebGPU implementation, so Mozilla will be contributing to Naga and wgpu, along with the rest of the community, to bring Naga into full WGSL compliance as soon as we can. But that's going to take a while - realistically, I wouldn't expect that we'd conform to a future WGSL 1.0 until early 2023.