Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wgsl] Document motivation for not just using GLSL? #610

Closed
pjoe opened this issue Mar 13, 2020 · 11 comments
Closed

[wgsl] Document motivation for not just using GLSL? #610

pjoe opened this issue Mar 13, 2020 · 11 comments
Labels
proposal question wgsl WebGPU Shading Language Issues
Projects

Comments

@pjoe
Copy link
Contributor

pjoe commented Mar 13, 2020

I am still scratching my head over why not just use GLSL instead of creating WGSL as a new shader language? I even saw references to: https://xkcd.com/927/ in the propsed FAQ 馃槅

All browser already takes GLSL input (for WebGL) so would assume some part of parser could be re-used.
All major engines (unity, unreal, godot) already produce GLSL output (for WebGL builds)
All WebGL engines/frameworks (three.js, Babylon.js, CesiumJS) already use GLSL
Also apps would need to ship a GLSL shader compiler, for those dynamic generated shaders that cannot be handled build time. This will add substantially to bundle size (shaderc is ~3MB, think glslang is ~1MB, compare to typical webgl engine size of a few 100K) and add extra processing: shaders now have to go: GLSL -> WGSL -> browser -> SPIR-V/DXIL/MSL.

Alternative would be to rewrite all shaders in WGSL, but on top of having to port API to WebGPU, I suspect for many smaller teams, this just won't be feasible. We e.g. have ~2.2K lines of GLSL code, that have been hand tweaked over almost 10 years - porting that to WGSL is not a trivial task for us.

I may be missing something essential here, but really don't understand the reasoning 馃槦

(Mostly copied from #593 (comment) - to be handled here as a separate issue.)

I can see others have similar concerns (#593 (comment)).

UPDATE: I think what is important is to have the motivation for not choosing GLSL well document and easily found, as I imagine other developers from a WebGL background will have similar concerns.

Also having a good (emerging) story on tooling for using GLSL with WebGPU, (e.g. optimized glslang with WGSL output, or other small and fast compiler) will help a lot :)
Also I assume the issue blocking from using SPIR-V (Apple vs. Khronos) doesn't apply to GLSL?

@dneto0
Copy link
Contributor

dneto0 commented Mar 13, 2020

I think that this type of discussion does not help at all

But it's a genuine question.

We've covered this ground over past meetings and email discussions. But not everyone can follow all the discussion in detail. Unfortunately the answers are not summarized in a way that is easily discovered or perhaps in a satisfactory way.

@dneto0
Copy link
Contributor

dneto0 commented Mar 13, 2020

Sorry I should have said "But not everyone can afford to follow ..."

@litherum
Copy link
Contributor

litherum commented Mar 13, 2020

I proposed this in September 2019 at the New Orleans WebGPU face-to-face meeting. You can read about it in the last 4ish pages of the minutes.

@pjoe pjoe changed the title [wgsl] Why not just use GLSL? [wgsl] Document motivation for not just using GLSL? Mar 14, 2020
@pjoe
Copy link
Contributor Author

pjoe commented Mar 14, 2020

I guess I am a bit late to the party here, sorry about that 馃巿

I've changed the title to reflect that what is probably needed is better documentation about the motivation for WGSL vs. GLSL.

I'll also try investigating further and contribute to how GLSL can best be used going forward, I understand from @dneto0, that there is already some work underway in regards to this.

@frguthmann
Copy link

I asked the people behind WebGPU on Twitter, here is a small thread with a few interesting links. Apparently it's the best they have so far.

https://twitter.com/frguthmann/status/1233316227633811456?s=20

@pjoe
Copy link
Contributor Author

pjoe commented Mar 16, 2020

@frguthmann thanks, I already saw the FAQ PR #562, actually I got the xkcd reference from there 馃槃

@frguthmann
Copy link

Yes I know but there is more in the thread. Twitter's UI is not always the easiest to navigate though haha. The most interesting tweet is this one: https://twitter.com/dneto1969/status/1233406310294720515?s=20

@pjoe
Copy link
Contributor Author

pjoe commented Mar 16, 2020

thanks, must admit I'm not a twitter regular ... anyway would be good to have it documented properly somewhere 馃槃

@dj2 dj2 added the wgsl WebGPU Shading Language Issues label Mar 17, 2020
@grorg grorg added this to Under Discussion in WGSL May 9, 2020
@litherum litherum moved this from Under Discussion to Resolved: Needs Specification Work in WGSL May 26, 2020
@dhardy
Copy link

dhardy commented Sep 27, 2020

Let me side-step the round-trip to Twitter by re-linking the contents of those posts:

The latter positions are long threads and it is not immediately obvious how conclusions were reached.

@kvark
Copy link
Contributor

kvark commented Sep 28, 2020

There is also #219 and #847. I think the short answer is that there is no appetite within the group for GLSL. Let me try to elaborate.

First, we wouldn't be able to use the GLSL as it stands today. We need separate textures and samplers at the very least. So it would be more like the Vulkan GLSL flavor but without Vulkan part. Needless to say that the extension tries to fit the existing GLSL syntax as much as possible, and as such users have to construct sampler2D and stuff on the fly every time they need to sample or fetch any texels. This is a hack more than it's a design anybody wants to buy.

Secondly, GLSL was made for the world where each shader only had a single entry point and execution model. This doesn't match either of SPIR-V, HLSL, or Metal. We could try to stretch it apart and try supporting multiple entry points, but then we'd hit other problems like conflicting locations and binding points. And again, it wouldn't nearly be the same GLSL for either users or the tooling.

So we'd end up specifying a "WebGPU GLSL flavor" of sorts, and that's a fairly big document, given the number of changes we'd need. In addition to the language spec, we'd essentially need to define the environment spec. I mean things like the strict behavior of operations, what happens on out-of-bounds, and other things.

Finally, there is a historical reason. Part of the group still saw SPIR-V as a superior alternative, and was hoping to get that ball rolling without being distracted by GLSL. In fact, original WGSL proposal (Tint) was pretty much an original textual form of SPIR-V. Now it's diverging more (hence, it's a historical reason).

Also I assume the issue blocking from using SPIR-V (Apple vs. Khronos) doesn't apply to GLSL?

SPIR-V had more reasons to be blocked (see plain and component argdown views). But really, GLSL is in the same boat, isn't it? It's also a Khronos spec.

@dj2
Copy link
Member

dj2 commented Sep 28, 2020

Thanks for the great writeup @kvark. I'm going to close this as I think that explanation does a great job of documenting the decision.

@dj2 dj2 closed this as completed Sep 28, 2020
WGSL automation moved this from Resolved: Needs Specification Work to Done Sep 28, 2020
ben-clayton pushed a commit to ben-clayton/gpuweb that referenced this issue Sep 6, 2022
鈥uweb#610)

Completes a TODO in api,operation,buffers,map:*

Uses mappedAtCreation or mapAsync to write to various ranges of variously-sized buffers, then uses mapAsync to map a different range and zero it out. Finally uses expectGPUBufferValuesEqual to verify that contents originally written outside
the second mapped range were not altered.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal question wgsl WebGPU Shading Language Issues
Projects
WGSL
Done
Development

No branches or pull requests

8 participants
@dj2 @kvark @dhardy @litherum @pjoe @frguthmann @dneto0 and others