Skip to content

WGSL 2020 04 21

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

Tentative Agenda

  • Issue #645 - Add GPUShaderModuleDescriptor/sourceMap
  • Description updates by dneto@ (#710, #711, #712, #713)
  • Issue #569 - [wgsl] Consider adding sugar for familiar loop constructs
  • Issue #685 - want a syntax for "the zero value" for bool type, numeric types, and compositions of them
  • Issue #707 - what is the rule for mixed-signedness operands to integer div, rem, less-than, greater-than, less-or-equal, greater-or-equal
  • Issue #709 - support C99 hex float literals to accurately capture float values
  • Issue #714 - is a switch default clause always required?
  • Issue #715 - proposal: permit redundant as-casts

📋 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
    • Tex Riddell
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Joshua Groves
  • Mehmet Oguz Derin
  • Timo de Kort
  • Lukasz Pasek
  • Tyler Larson
  • Lukasz Pasek
  • Pelle Johnsen
  • Matijs Toonen

📑 Prior Cheat Sheet

Aggressively summarizes (strictly) only the updates from YYYY MM DD - 6 to YYYY MM DD.

This cheat sheet was built by the scribe who would hugely appreciate and improve based on feedback, contact using mehmetoguzderin@mehmetoguzderin.com

❓ Issues ❗️ Pulls
#IJKL MNOP
📣 Author 📢 Opinions
  1. No Update
  1. A: Opinion A
  2. B: Opinion B
**#RSTU VYWX**
📣 Author 📢 Opinions
  1. No Update
  1. A: Opinion A
  2. B: Opinion B

📐 Meta

  • Reminder: if you’re going to make a new issue/proposal, it needs to be submitted at least 48 hours before the meeting.
  • DM: In the main group we’re using the github project for agenda formation. There is a column “Needs discussion” - if you want something on the agenda you put it there, and we try to order things in that column.
  • DS: Would make my life easier! Is it extra work?
  • DM: You can do it from the issue or PR.
  • DS: It’s on the right hand side. You might have to create the issue first.
  • DJ: I’ll take an action to make that column, and move anything that didn’t get addressed in this meeting into there.

⚖️ Discussion

Issue #645 - Add GPUShaderModuleDescriptor/sourceMap

  • JG: Feedback it’s different because differences can be observed between the things. Differences in interpretations can be observed. Isn’t a standardized ingestion formation. What concerns do people have here with Source maps? Not a lot of traction but seems non-controversial to me
  • DM: No concerns until David commented
  • DN: Low level rising concern. How do you know what version of the source map you’re using? Do you need a new version if the map changes?
  • JG: Imagined the source map has a version
  • KN: There is aversion field in the sourc emap value
  • JG: The can I use would be ‘GpuShaderSourceMap(v4)’. Wouldn't be super discoverable but would be usable
  • MM: Would want to know what the browser supports before you supply it.
  • JG: Don’t have an immediate answer, but should be a problem we can solve.
  • DM: Should we use extension as a solution?
    JG: Don’t think so
  • DM: Could be an extension ‘source maps version3 available’
  • JG: Seems heavy weight
  • KN: Doesn’t need to be explicitly enableable so doesn't need to be an extension
  • JG: Not revving source map version all the time because the JS source maps have a simpler problem. They have a worse problem as you can’t determine what version to serve. So, no worse off then what’s shipping
  • KN: Versioning doesn’t seem like a big deal, can pick version 3. Won’t break app if browser stops understanding source maps, so only needs to work with the time the source was written
  • JG: Can clarify the proposal that it’s v3 and if we want to add something else can talk about it later. Don’t see any roadblocks with there being a v4 later and adding some kind of v4 support to the shader map.
  • KN: I agree
  • DP: Important thing is to never remove v3 support.
  • JG: Yup. web platform.
  • MM: Are source maps in JS API?
  • JG: Part of the web platform but not exposed for reflection. Standardized hint for the user agent
  • MM So why add it as API here?
    JG So you can transform code back out. To make that easy
  • DM: Establishes a pipeline to the underline shader compiler so you can generate debug data
  • MM: Mis-stated question, not why are we allowing source maps, but is there another way to associate the source map to wgsl code?
  • JG: JS does it as annotations you describe as a URL. You embed in the source a source map annotation which is a URL the UA can fetch and interpret. I dont’ think that works as well for us because there is a lot more runtime generated code. Would need to synthesize a shader URL.
  • MM: Would be a data URL
  • KN: (via meeting chat) We could take the same approach as JS, in that the page can't tell whether the source map was used or not. And you have to use a userspace library to do your own source mapping (which is done in JS today) Source map urls make very little sense to me for shaders
  • JG: Could do that, but seems to be an extra leap. The main difference, with the URL you could defer the generation of the source map in the output json until it’s fetched. Other things we could do, you could make it a callback that returns the json object out of
  • DP: In a pipeline I see this being used in a pipeline shader compiler. If it is an API it is up to the app to load the source map alongside the shader code and hand both of them to the API. Thinking of it that way the URL seems more …. <misssed it>
  • JG: …
  • DP: Does the url let you do some kind of …
  • JG: It could, generally speaking I don’t think URL fetches differentiate based on headers.
  • GR: This would need to be a real valid URL which could be retrieved, not just something to satisfy the requirements.
  • JG: In theory could be a URI. So, could be a blob URL, some page local temporary thing.
  • KN: So should consider if we need to expose the map data back to the page because JS does not do that. Pages can still implement functionality (like a typescript playground) by having a userspace source map implementation and mapping the generated JS API error lines back through the library. THat way, the particular version of source maps will never break a page. Browser dev tools may stop understanding but won’t break the page.
  • JG: The real thing this gives you is a standard API the UA gets access to this data. You could always do userland source mapping. We have the opportunity to let us have a standardized interface. Clear way to opt-in to having UA browser dev tools interact and service this data. That’s attractive from a UA standpoint that wants to provide good dev tools
  • MM: One other point, we haven’t talked to our JS team about this source map version yet. We may come back and say we’d like changes. At a high level source maps are probably a good idea, the fact if they change won’t break your app makes me worried, so explicit API could be troublesome. So, from a high level seems like a thumbs up.
  • JG: Can I get commitment to talk to your team
  • MM: Yes
  • KN: I think it makes sense to pass it in as an API, but it does seem a little iffy. Let’s stay on the path JS uses. I think it is ok for a page to use a sourcemap library when they need it.
  • DP: I think your feedback on the other pull request with mapped error messages
  • KN: Just passing the source map the API wouldn't affect page behaviour as long as it doesn’t throw an error
  • MM: Is this feature untestable?
    JG: No, this in concert with structured error messages would allow you to test it.
  • KN: Without mapped error messages would be as testable as source maps in JS. Browsers have to have their own source map tests
  • DP: Conformance testing?
    KN: I don’t think there is such a thing as conformance. If the browser doesn’t support them the page behaves the same way
  • DP: Could see that as a motivation to not stick to the source map spec and could end up with a browser specific source map format. How concerned are we about that?
  • JG: Seems like we should do better than that.
  • DM: Don’t we have it observable in the compilation message?
  • JG: It’s observable but there is a seed to make it not observable.
  • DM: How would it affect 646?
  • JG: To make it not observable would have to remove mapped structured components from 646.
  • JG: Will probably remove mapped structured components from 646 and push forward as 645 is taking longer than expected. Related but orthogonal proposals. Would like commitment from folks who might later object to get feedback on if exposing source maps like this is feasible.
  • DJ: Will take that action, someone from Google to do the same? Who can talk to dev tools?
  • JG: I asked who’s our source map person and got the right person. Not absolute feedback, just want to make sure it’s viable
  • KN: Unlikely we’ll have feedback other browsers won't’ have but can try to find someone.
  • JG: Basically any feedback before approving PR:
  • KN: I’m OK with it behaving either way
  • MM: Will take back to source map team
  • DJ: Will come back to this next opportunity.

Description updates by dneto@ (#710, #711, #712, #713)

  • DJ: Say we just approve 710 without discussing
  • MM: 711 talks about constructs we haven’t agreed on which isn't’ a deal breaking just. Additional explanation is good, reflects current state of spec, just wanted to make sure this additional explanation may or may not change based on other discussions
  • DN: That was the intent I was trying to get. Several things were not written down. Just trying to get words down to the original intent with the draft. Does not resolve or drive any conclusions, just explaining original proposals.
  • MM: Ok
  • DJ: Sounds good. 712 has one question
  • DM: Would say a function declaration return type is void, should not be written as a generic type as you can’t use it
  • DN: Does hwo up in other places in SPIR-V since an extended instruction can return void or not a value. Vector stores in OpenCL-C but this may not happen in WGSL. Can re-visit when we get back to it
  • DM: Isn't’ that just a function decl on our side?
    DN: It is that way in in open-cl-c but we could have a subgroup barrier, but is that a built in function? Kinda not like a function in some ways. Up in the air as a design question.
  • DJ: 713 awaiting review,
  • DN: Not sure the norm here as we have multiple editors.
  • DJ: We have the procedure that we have at least one review, just wanted to see if we could have a group of people added who want to be the default reviewers. Manually and editors can keep an eye out.
  • DJ: I think we can finish these off by commenting on the issues.

Issue #685 - want a syntax for "the zero value" for bool type, numeric types, and compositions of them

  • DN: Hasn’t moved much. Handy to be able to say null of a null-able type. Would like a syntax for that. JG and KN pointed out that default values for variables means we can use a constructor argument to denote the zero value. Seems fine to me. Means we don’t have to pick another word.
  • RM: I agree it seems nice to add this.
  • DM: Are we going to have constructors for types?
  • DM: e.g. const xx: vec3&lt;f32> = {};
  • DN: so this is for POD-style types. You can construct a vector of 3 floats by saying const xx : vec3<f32> = vec3<f32>(0.1, 0.2, 0.3). Also in general creating a value of any composite, type e.g. arrays, structs, and recursively.
  • MM: so the code snippet would not work as it doesn’t have squigglies?
  • RM: const xx: vec3&lt;f32> = vec3&lt;f32>(0.1, 0.2, 0.3);
  • KN: my proposal is ^, plus: const xx = vec3&lt;f32>();
  • DN: I initially had: const foo vec3&lt;f32> = null&lt;vec3&lt;f32>>;
  • KN: We coooouuuld adopt C++ construction syntax:
  • KN: const xx = vec3&lt;f32>{0.1, 0.2, 0.3};
  • KN: const yy = vec3&lt;f32>{};
  • KN: if you don't want it to look like a function
  • DM: So if i specify arguments then i initialize with the given values and if i don’t give values it gets zeros? Like, a default constructor?
  • DN: Didn’t have that in mind but if you skip the values vec3&lt;f32>() it gets defaults
  • DM: Seems like function overloading, same call with different arguments
  • MM: Already have overloading with operators, can add two floats or two ints.
  • DM: Right, there are languages where you can overload operators but not functions
  • JG: From a lang point of view i don’t think overloading is a scary thing that we should avoid in a shading language.. Not strong feelings, valuable to have short hands as long as there aren’t too many and not too complex. GLSL has this.
  • DM: So vec3() in glsl would get 0’s? That’s surprising
  • JG: vec3(1) gives vec3(1, 1, 1)
  • DM: That’s different, that’s a different rule, that’s an implicit cast from scalar to vector.
  • JG: Maybe but vec2(1) is different from vec2(1, 2);
  • DM: Don’t want implicit cast from GLSL. Not a good example of what we should do.
  • JG: Maybe less objectionable, if the two overloads are no arguments or all of the arguments.
  • MM: One thing that might be helpful is where else would these default initializers be used in the language
  • DN: Anywhere you can supply a value. Ends up being a constant 0 value, so function calls, stores, nearly everywhere. Because it’s a constant it’s resolved by the frontend, not a thing executed at runtime. It’s effectively static data that becomes a value.
  • MM: Would it be used for const without an initializer?
  • DN: I think const should always have an initializer. We already have variable default initialization because it’s zero initialized. This is if you want to start with something blank and fill in an comp value. In LLVM you start with an undef vector and you inset. We don’t want undef so you have zero value and start manipulation. Just a shorthand for the zero blank value.
  • MM: Feature is letting the user type what the compiler would do naturally.
  • DN: Yes.
  • JG: Sortof, we’re going through a high level and the optimizing compiler is going to do something. This is if you want to do something like this that branches then fill in the parts of a vec3 differently. From the spec standpoint we want to say what’s happening but what the compiler does is up to the compiler. So, not so much what the compiler really does but specifying the behaviour that we really want.
  • DM: Wouldn't' we have it specified that everything is zero init until proven otherwise.
    • [conversation from chat]
    • KN: Dzmitry, argument that GLSL vec3(1.0) is an overload, not an upconversion from float to vec3: vec4(float, vec3) et al
    • DM: where is this described?
    • KN: link to GLSL ES
  • JG: This lets you do it as a value without having to name something. Gives an RValue instead of an LValue. Say you’re texturing from something and you know you want the origin you can just say vec2<f32>() and that gives a value instead of a name.
  • DM: Seems that this is a small use case instead of getting the user to do it. We could go with default instead of depending on user to do it
  • JG: Two sides of a coin. When you have variable decks you can choose to never have the type. You can do that if you have a reasonable way to choose, given a value that yields that type. So it can always be inferred. You can choose either approach, we have two ways.
  • DN: Against having to declare a variable to get this initialization; and a constant must always have a value. A variable always denotes storage.
  • JG: A bit of friction as we talk about variables and Variables. At least I do. Is a const a variable? Not a Variable variable.
  • DN: To me variable is always storage and const is a name for a computed value.
  • JG: So a named value.
  • DN: Yes
  • DM: Useful to have constants. Zero constants are not special. Convenient to initialize a variable to 0, as that’s what’s in the spec. Other constants are also useful but don’t need special constructs. E.g. IdentityMatrix.
  • JG: For me, often infer the type on the left from the literal type on the left. So my preference is to always infer the type when you can get away with it. Would help a lot to have a vec3<f32>() to say an uninitialized vec3. A cleaner expression of intent then saying a uninitialized named variable/constant is zero initialized. It’s more explicit with the equals as it looks like an assignment but it’s also more implicit. Would prefer to have the vec3&lt;f32>() as it’s clearer.
    • KN (offline):
    • const xx: vec3<f32>;
    • vs
    • const xx = vec3<f32>();
  • DJ: This has been a good discussion, but there is more content here than in the issue. Let’s pause, put our respective thoughts into the issue, then continue at a future meeting.

Issue #707 - what is the rule for mixed-signedness operands to integer div, rem, less-than, greater-than, less-or-equal, greater-or-equal

  • DN: At some point I think we discussed what to do about integer operations where the type of the operands are mixed. So U32 * I32. Sticks in mind that it was said we should ban those mixtures. Which is fine with me you just have to make sure the types map. Wanted to make sure we all agreed. The cases I listed were the ones I could find in SPIR-V with an S or U operation. Then we can codify and be done.
  • JG: No objections
  • DM: Sounds great
  • DN: Coming from SPIR-V you can mix at will and the semantics is embedded in the opcode so you have to do casts on the input to get to the right type to have them appear correctly in WGSL. May have to case back out on the flipside.
  • TR: Sounds good but one concern with literals. How do you handle literals where you have 1 and -1? HLSL has a special linteral int type which is a 64-bit signed type which is collapsed to the combined yet when you have something which needs it. Don’t know how we’d handle that in this language.
  • DN: Same approach as Go language where literals are typeless until the type is needed
  • KN: Rust is the same as well
  • DS: In Tint right now, literals have specific types associated with them. When it converts to SPIR-V, all constants are of a specific type.
  • TR: How would you express that?
  • DS: Unsigned has a “u” on the end of it. Otherwise it is signed. Float has to have an “f”.
  • JG: We can talk more about literals separate from our typing rules. I think we can move forward on this issue now, then come back to literals. Let’s have these type assignments now.
  • TR: I like the “u” on the end rather than a specific type assignment.
  • KN: I agree. I like it too. Something that plays into both literal types and default/zero types (above) is, “should every expression have a known type?”
  • KN: I think it is good to have each expression to have a known type if feasible.
    • KN (offline): Aside: makes it possible to omit type annotations on const/var - they become simple type assertions (there’s only one valid type annotation). Can even remove them from the grammar (I think JG proposed this before?).
  • TR: it makes it uglier, but it makes it clearer
  • TR: fear that with extra types we might need more suffixes which can get cumbersome. e.g. f32, f16, etc
  • DN: my normal style in C++ is to use the constructor syntax to do the value cast up. I’d write uint64(1). Seems a good way to proceed to use this to do type conversions in WGSL.
  • MM: The letters on the keyword are as
  • DN: as is like reinterpret_cast in C++ and type initialization is like a constructor. as is a bit cast
  • DM: Idea behind knowing type of expression was discussed in 560 which is very related.
  • DJ: Jeff’s suggestion, can we accept this now and do literals separately. No-one against?
  • GR: We may have resolved literals as well.
  • JG: Maybe?
  • DM Wouldn't' rush into that
  • DJ: Someone should write up in text what we just discussed. Let’s finish the discussion on this issue and assume we’re agreed. Then we can resolve and someone can open an issue on the literals.

Issue #709 - support C99 hex float literals to accurately capture float values

Issue #714 - is a switch default clause always required?

Issue #715 - proposal: permit redundant as-casts

Issue #569 - [wgsl] Consider adding sugar for familiar loop constructs


🗓 Next Week

Clone this wiki locally