Skip to content

WGSL 2020 03 17

Jump to bottom
François Daoust edited this page Dec 2, 2020 · 1 revision
Dean Jackson

:

 🪑 Chair
Mehmet Oguz Derin
  1. Scribe’s Preface: I am new to scribing, and I tend to write using telegraphic sentences. Please let me know or edit where needed.

:𐰆𐰍𐰔 :

 ⌨️ Scribe
Google Meet 🥩

:

 Location
https://webgpu.dev/wgsl

:

 Specification
WGSL Issues

:

 Open Issues
Marked Issues

:

 Meeting Issues

TL;DR

  • General agreement to validate the grammar in the CI system.
    • Jeff Gilbert and Mehmet Oguz Derin to investigate.
  • Offsets in structs are going to remain in the grammar.
    • Open question on if we wanted the std140 or std430 attribute for structs
  • Discussion around versioning and extensions for WGSL
    • When needed, general agreement seems to be to have it inband inside the WGSL file.

Tentative Agenda

📋 Attendance

WIP, the list of all the people invited to the meeting. In bold, the people that have been seen in the meeting:

  • Apple
    • Dean Jackson
    • Fil Pizlo
    • Myles C. Maxfield
    • Robin Morisset
  • Google
    • Dan Sinclair
    • David Neto
    • Kai Ninomiya
    • Ryan Harrison
    • Sarah Mashayekhi
  • Intel
    • Yunchao He
    • Narifumi Iwamoto
  • Microsoft
    • Damyan Pepper
    • Rafael Cintron
    • Greg Roth
    • Michael Dougherty
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Joshua Groves
  • Mehmet Oguz Derin
  • Timo de Kort
  • Lukasz Pasek
  • Tyler Larson
  • Lukasz Pasek
  • Pelle Johnsen

📑 Prior Cheat Sheet

Aggressively summarizes (strictly) only the updates from 2020 03 11 to 2020 03 17.

This cheat sheet was built by the scribe who would hugely appreciate and improve based on feedback, contact using [email protected]

❓ Issues ❗️ Pull Requests
#581 Comma operator
📣 Author 📢 Opinions
  1. No Update
  1. A: Complex continuing won’t be common, a product of inlining. Shaders work on already parallelized context (as a counterargument for multi-part increment).

#569 Sugar for Familiar Loop Constructs

📣 Author 📢 Opinions
  1. No Update
  1. A: break as the only exit is not restrictive

#592 Entry Point Input and Output Globals

📣 Author 📢 Opinions
  1. No Update
  1. A: Scan and solve

#601 Rusty Syntax Incompatible with C, C++

📣 Author 📢 Opinions
  1. GLSL and HLSL reflect C, so should WGSL consider
  1. A: Duplicate
  2. B: Not group’s goal, out of scope

#600 Plan for Expansion

📣 Author 📢 Opinions
  1. No Update
  1. A: Version directive be at top
  2. B: Version directive only necessary if backwards incompatibility

#568 Preprocessor

📣 Author 📢 Opinions
  1. No Update
  1. A: Existing shader code has many ifdefs

#609 Syntax and Porting

📣 Author 📢 Opinions
  1. This deviates too much, make it more conformant or release official libraries for tooling
  1. A: Tooling won’t be official
  2. B: Officially recommended tooling is a win

#579 Continuing Block

📣 Author 📢 Opinions
  1. No Update
  1. A: Let third clause be single statement, needs either scoping as at end of loop body or hoisting loop body variables

#612 Push Constants

📣 Author 📢 Opinions
  1. Not in WebGPU, why in WGSL?
  1. A: Let’s remove

#610 Document the why of not just use GLSL?

📣 Author 📢 Opinions
  1. GLSL is already established, the opt-out should be clarified
  1. A: Previous discussions already contain detail on this
  2. B: A concise summary would be good

#593 Reason Behind Rusty Syntax

📣 Author 📢 Opinions
  1. No Update
  1. A: What about GLSL to WGSL people?

#606 Support #line Directive

📣 Author 📢 Opinions
  1. Add #line and #endline that corresponds to OpLine and OpNoLine
  1. A: Little uneasy, should have a familiar construct
  2. B: Better have sourcemaps

#603 Intrinsics and Their Arguments

📣 Author 📢 Opinions
  1. Have them take more general inputs rather than unary
  1. A: Can do, is a clarification

#616 Exclude Builtins and Intrinsics from Grammar

📣 Author 📢 Opinions
  1. These should live as builtin functions, not part of grammar
  1. A: There are only 8 of them, not many of them and not about to change soon

#620 Is SPIR-V ⇔ WGSL Feasible

📣 Author 📢 Opinions
  1. Is it feasible as advertised?
  1. A: Yes. Based on prior art.
**#599 Update Goals**
📣 Author 📢 Opinions
  1. Update according to discussions
  1. A: Text-based is redundant

#602 Fix Derivative Modifier

📣 Author 📢 Opinions
  1. Typo fix
  1. A: Landed

#588 Update Goals

📣 Author 📢 Opinions
  1. No Update
  1. A: SPIR-V matching should exist in README, not spec
  2. B: That’s important to convey that spec works as a shader language and does not specify hard or ambiguous language

#615 Remove Push Constants

📣 Author 📢 Opinions
  1. Not in WebGPU, not in WGSL
  1. A: Landed

#604 Intrinsic and Derivative Expression

📣 Author 📢 Opinions
  1. Clarify intrinsics and derivatives
  1. A: Landed

📐 Meta

  • WGSL meeting notes now have a new layout 🎉 Any feedback would be immensely appreciated 📈

🔗 Issue #578 - Validate the grammar on CI

  • DM: We have a lot of mistakes in the grammar that could be easily fixed by machine checking. We should define a proper format and tooling to convert to. But I don’t feel too confident about options, we need to decide together.
  • DN: I think it is a good idea, automated testing is good.
  • MM: Same here. No opinion on the mechanism.
  • DS: If someone’s going to make the conversion, that’s fine.
  • DJ: Which format then?
  • DS: Grammarkdown?
  • DM: Yes, that one
  • DJ: Anyone disagree?
  • Volunteers to look at the work: JeffG and Oguz
  • Resolution: Accept grammarkdown for now. Revisit if it doesn’t end up to be a nice fit.

🔗 Issue #561 - Offset decorations on Structs

  • DJ: Many inputs on this one
  • DN: I have background on this.
  • DS: Right now you have to explicitly set the offsets. Rationale is Vulkan world have many representations, all weird and hard to get right. I just fixed a bug. Other tricky part is that UBO layout is discrete from SSBOs. So it makes sense to be explicit and make it more predictable for the users. Jeff’s suggestion is good. So explicit but also clued.
  • JG: I think only downside, I like it but, it is really verbose. Other way is not better for sure. Experienced trouble with the layout setting.
  • MM: I think it is conflicting to try to match SPIR-V and readability in this one. We should try to keep this readable. I’d like to be data-driven about this. We can get sample of people to provide code. I don’t disagree that this makes things easier during development but we should keep the door open.
  • DN: Backstory. GLSL has two versions. Driver dev said this is mess and spec is hard to read. Some said you got to be really explicit. This is actually more about Vulkan because SPIR-V does not dictate layout. ... . As we tested more real (not academic) things, we kept adding relaxation enums. Yes, I see that it is verbose and hard to get your first thing working. But we can fix that with tooling. ANGLE team had many troubles with this, so the way to go forward is to be hundred percent verbose.
  • DJ: If it is possible to make tooling, why can’t we just process on our side?
  • JG: I don’t think it is completely possible to provide a tooling that will tell you what’s wrong on every occasion. Because it has two faces, API side and shader side, which is kind of natural given that this is in GPU programming context.
  • DJ: My question then is, don’t writing explicitly on two sides give twice as much chance of failure?
  • JG: It is impossible to say what’s done wrong on the host side (because it is a bit blob), this is a shader side concern.
  • KN: Strongly agree. Have to have the data somewhere: offset in the shader, an extra validation-only dictionary in API (functionally same), a reflection API (not validatable, would be error prone, either by providing offsets or somehow with DataView). Only other way is that you have a system available to you that creates exactly the same layout (e.g. if you can mirror the struct between your C code and your shader code).
  • RM: I have a question, what’s the DirectX’s standpoint on this? How does all this work on that side?
  • MD: We support a couple of different modes.
  • MM: Is it possible to be explicitly set offset for the first element in HLSL?
  • MD: I have to check that.
  • GR: I am pretty sure that we don’t support that.
  • MD: If we go forward with this round-trip might be more messy with HLSL
  • DN: Vulkan is general.
  • JG: I think the only downside to the explicitness is verbosity, we can just add that and check the feedback.
  • DM: What will be the rules?
  • JG: We can do std140 and std430
  • MM: I think if we only have a small set of layouts, that is an argument for not needing explicit offsets.
  • JG: We have evidence that people have made mistakes even with the standard layouts, because the rules are difficult.
  • MM: How’s this going to work with WebGPU?
  • JG: I think we need an investigation about layouts.
  • MM: So can we put the first element after second?
  • KN: There will still be invalid layouts.
  • DN: Padding must be a multiple of the natural alignment. Difference between 140 and 430 is 16 alignment. We might want to be more constrained and keep it 32 everywhere. An investigation would help.
    • see: VK_KHR_uniform_buffer_standard_layout
  • DN: People want to write one set of shaders and target many platforms.
  • MM: I think Jeff’s proposal is acceptable as a starting point.
  • DJ: Anyone disagree?
  • DM: We should make the layouts more understandable.
  • JG: I can make a PR.
  • MM: Emphasis on readability.
  • JG: I will say this makes it even more readable.
  • DJ: Anyone having problem with syntax choices?
  • DN: Sticking with C++ styled is fine.
  • DJ: Double square brackets and so on.
  • KN: Three options: not there, required, optional and we’ll validate.
  • MM: What’s the benefit of doing this when we have ArrayBuffer on JS side?
  • KN: I think this makes things easier for some backends. …
  • MM: (but then some implementations could just not implement it)
  • KN/JG: All have to implement the validation rules, or portability breaks.
  • RM: Can’t we just have layouts and work it out? If we have explicit offsets, we have to check that on backend too.
  • JG: …
  • RM: …
  • JG: …
  • MM: …
  • JG: Can we call this issue orthogonal to offsets, so I can go implement the PR before we resolve this issue?
  • MM: Doesn’t this make it harder to author?
  • JG: If authors get this wrong, then author won’t be able to create proper shaders.
  • MM: Most of the shaders on the world do this without explicit offsets.
  • JG: Actually many of these are ambiguous in nature.
  • DJ: Why the struct also needs layout besides explicit padding? Only for backend convenience?
  • DN: I think this will only be used for validation. Can be done in backend implementation, it should be inferrable.
  • DJ: So it is possible to infer working layout from offsets.
  • DS: Layouts would help a lot for hinting the author.
  • MM: Why should author care?
  • JG: Because it is necessary.
  • DJ: So I think we agree on the offsets.
  • DM: For GPU-to-GPU communication, offsets are redundant.
  • DN: In Vulkan, these only matter for host-device communication.
  • DJ: I think we should close this issue and Jeff should take the steps laid out, open new issues and refine further.

🔗 Issue #600 - WGSL needs a plan for expansion

  • DN: There is a tendency to clutter designs over time with additions. We need a way to version things so that developer can tell us what they are actually targeting. GLSL does it one way, HLSL does it another way.
  • RM: I think we should not have discrete expansions that you can mix and match. That creates a huge problem space to work on. We should add things linearly, and such version linearly.
  • MD: We need to version the language and features. This is clear to distinguish.
  • DN: I agree with RM that we should restrict variations. I think we will naturally conform to that because we are strictly targeting subset of many hardware.
  • MD: (opinion about relation of language and feature versioning)
  • JG: I think it is valuable to keep things separate.
  • DN: So, in-band or out-band?
  • JG: I am in favor of in-band because it makes it easier to read.
  • DN: Having in-band is easier to verify.
  • JG: In WebGL, we even try to inbandify things.
  • MD: HLSL is out-of-band for all of these. Do we put this at top?
  • JG: You always try to put them at top. Extensions can be a bit down the page.
  • MD: This and last section will hurt us about compatibility with DXIL. We need to take a look at these and give feedback. We will definitely go from HLSL to WGSL and probably vice-versa, so we need to give a thought about this.
  • DS: We will need to target DirectX.
  • KN: We will even try to target DirectX 11.
  • MD: These are large topics, we will take a look. Offsets will be an issue.
  • KN: I think SPIRV-Cross already handle these.
  • DJ: What’s the resolution?
  • JG: Still under discussion.
  • DN: Support for inband.

🗓 Next Week

  • Issue #578
  • Issue #600
Clone this wiki locally