WGSL 2020 06 09

Dean Jackson	:	Chair
Mehmet Oguz Derin	:𐰆𐰍𐰔 :	⌨️ Scribe
Google Meet	:	Location
https://webgpu.dev/wgsl	:	Specification
WGSL Issues	:	Open Issues
Marked Issues	:	Meeting Issues

Tentative Agenda

• Lots of things need proposals
• How to close older "discussion" issues? e.g. #593
• Textures (#573)
• wgsl: Fix conditions on break from continuing (#837)
• type foo = struct is unfamiliar (#735)
• Remove is_finite and is_normal intrinsics. (#841)
• Requiring integral-valued float literals to have .0 seems gratuitous (#739)
• Add 0/1 swizzle syntax (#732)
• entry_point_decl should be an annotation on the function (#662)
• No explicit grammar for decorations (#689)
• C-like declaration order (#677)
• Support #line directive (#606)

---

📋 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

---

⚖️ Discussion

Lots of things need proposals

• DJ: Lots of things for MVP marked as under discussion or needs investigation. How should we distribute the work? We could wait for the editors or farm out the work to other people.
• DN: Backlog of changes that have gotten rolled in. There is a backlog which can be rolled in. There is a missing document plan on (...). Had the notion of writing an outline of section headers. Need a plan we can execute too. Would require someone to make a plan.
• DJ: Section headings would help. Makes it feel like they should be there vs a note in the project. Would be clearly missing.
• MM: There is a difference between “needs investigation” and “needs editing”. Editors are on the hook for the parts that need editing.
• DJ: Maybe start with someone making the skeleton outline in the spec. Then we can arrange the columns into some that need words and some that need investigation. Maybe one of the editors could do that skeleton.

How to close older "discussion" issues? e.g. #593

• DJ: Some older issues with lots of discussion but fizzled out. This one is rust like syntax inheritance. Don’t know how we should close this, we may not make the originator happy either way
• MM: For this specific topic, we have at least one document that isn’t normative that we could put the explanation into.
• DJ: Yes, that’s true. There are also a bunch of issues open on that non-normative document which folks are probably not excited to work on. General question, should we go through and close out and point to the FAQ? I’m happy to do that, some people will be annoyed.
• DN: SOmetimes a question is an opinion in question form and sometimes it’s ok to disagree and close.
• DJ: Glad to have the questions in theses forms. We can have a discussion.

Textures (#573)

• DS: This was me trying to gather data. We know we need to add textures. I just looked at all the platform libraries. Myles pointed out that WebGPU has a smaller set of textures. David pointed out that we also have restrictions on depth due to Vulkan.
• DS: Maybe we could start with non-depth textures and come back to depth later?
• MM: As long as we make an intentional decision about how the types are supposed to be related to each other
• DS: Anyone find it unpalatable? GLSL has shadow.
• DN: “shadow” is the reason they introduced depth textures, but now they vaguely mean the same thing.
• JG: For me, a depth sampler just happens to be comparing depth, but you can do it with other samplers. It compares the value you give it (in 3d) and compares the z value.
• JG: Are there any restrictions on normal depth texture samplers in any of the APIs?
• DS: MSL has named depth samplers.
• MM: I can’t remember if it means you can’t sample depth with a non-depth sampler. My recollection is that the depth type is what identifies this.
• DM: MSL says that depths must be float
• DS: HLSL is similar
• MM: When we were working on WSL (not WGSL) textures were in the std library, I analyzed the existing libraries here: https://github.com/gpuweb/gpuweb/issues/667
• DN: Vulkan sets up depth/stencils attachments on the API side. Vulkan has some compatibility requirements between the image format and being able to sample depth.
• DM: But it is also a SPIR-V feature? [missed name of flag]
• DN: Vulkan ignores that flag. This is mentioned in the environment specification. (Appendix A)
• GR: Dx12 is similar.
• DS: So it sounds like there is one way to do textures, and you can use it for depth textures too.
• MM: But MSL’s restrictions means we need to have two.
• DJ: What does spirvcross do now?
• DN: Unknown.
• DS: We could start with two types now, and go to one if we realise we don’t need it.
• JG: It’s surprising to me that Metal makes this distinction. There is only one line mentioning it in the spec. Maybe we are misreading it?
• MM: I’ll look into this.
• DN: It sounds like GLSL had that distinction because older GLSL actually had the restriction.
• JG: Even WebGL allows you to sample depth with texture2d. Generally speaking they are just texture formats (maybe with some filtering restrictions).
• DS: Quick look at spirvcross - for GLSL they go from shadow to depth2d.
• JG: DN brought up that there is a depth flag that is ignored in SPIR-V, maybe that’s how it gets surfaced for MSL translation.
• MM: Let’s come back to it next week when we have better information.
• DM: Is there a case where someone would want to use the same texture for comparison and non-comparison?
• JG: Yes
• DM: But they can always use two bindings.
• JG: Three things that people want to do \

1. sample from colour \
2. sample from depth \
3. depth comparison
   Question is how we deal with sampling a texture as a float value.

• JG: We will find out if this needs to be different.
• DM: It seems unlikely that the Metal team will rewrite their spec.
• JG: Maybe they meant colour sample a depth texture, and then it would match other APIs. So I think we need confirmation.
• JG: For now, we could at least fill in the entry points for color sampling.
• MM: Agreed. Pretend depth isn’t an issue at the moment and come back when we have info.
• JG: Does metal have stencil sampling?
• MM: Not that I know of.
• DS: I will continue writing a proposal.

wgsl: Fix conditions on break from continuing (#837)

• DN: You can exit a loop from the bottom, and we need to permit that. It’s common for loops to be rotated so you exit from the bottom. Also what you get with do{}while. Original plan was break if but we don’t have that anymore. You end up with if () {break;} which is what this is trying to capture.
• DM: The do while is from which language?
• DN: GLSL
• JG: I don’t think there is a requirement for forbidding else and elseif clauses.
• DN: It makes it ambiguous on if it’s the last thing or not.
• JG: Maybe more true if we have a graph of statements in the AST then the end states for all of them are break or not. Break if and keep going is the same as if () { break } else {blah; }. That’s theoretically valid.
• DN: Yup. So, the point is this is in the continuing block. Continuing in SPIR-V is special, only entry is top and only exit is bottom. Either the backend or the exit from the loop. The terminating parts end up being a lot of machinery and complexity. You could get by with no else but makes it a lot more complicated for what is needed.
• JG: Can you have multiple break if’s in a continuing?
• DN: No
• JG: Just the one?
• DN: Just the one. You’re only required to have continuing if you have continue earlier that is separated
• RM: Can you have an if with an or or and inside and a break as the result.
• DN: So, if the condition is complex? That’s fine.
• RM: Yes.
• DN: You precompute the condition and it’s a boolean anyway.
• RM: Isn’t it simpler conditions due to short cutting?
  DN: Even with short-circuiting you still have a boolean value. The control flow to escape the loop happens once. The control flow for the block is localized.
• JG: Almost feels like what you want is a continuing and then unless as something like continuing { .. } unless { }
• DN: So, conditioning the backedge or exit of the backedge
• DN: That’s effectively what it is.
• JG: We could define it in terms of how it would look if we didn't have that. You’re allowed a break if it’s the only thing in it and the break is the last thing in the continuing block. Harder to say in spec language but even a blurb that it must look like this and they get errors if they do it wrong. Feels a lot like the end of a do/while and since we have so many restrictions ….
• DN: Like an optional while clause on the continuing. You only go back to the top of the loop if you have the while
• JG: It’s even more intrusive, but writing language on how to use normal if/break would be great. An example would help.
• DN: Sure. I can write an example for that.
• JG: Like the only way you can have a break if if () {break;} is the last statement.
• DN: In SPIRV terms, the only way you can branch out of the continuing is if it’s ( … missed … ). This bit is elementary but the post dominance carries a lot of machinery. I will add an example of good /bad cases and we can review again.
• JG: About the else portion is that trying to describe if (foo) {} else {break; }. Is that a construct we want to support?
• DN: Yup
• JG: Should be able to represent that as if (!foo) {break;}?
• DN: I’d prefer not to. It’s a thing I can pattern match and people reading the code can pattern match. I think it’s already supported.
• JG: This would let you directly emit the opcodes wanted but our previous decisions for if vs unless. The negation should be canonicalized.
• DN: I’m using Maciej’s form of canonicalization.
• JG: Seems not strictly necessary but a nice to have thing. Given we already desugar if (!foo) into unless (foo) feels like we should extend that understanding to if break where it becomes unless() { break; }.
• DN: Not sure what you mean
• JG: Will add more to the issue.
• DN: Having an empty brace after if is already part of the language and I’m using it. if (!cond) { break ; } can also be used.
• JG: Seems weird for if (foo) break without an else but also support if () {} else { break; };
• RM: Can we get an example of allowing extra code in the condition before the break. Struggling to see why it would be hard to compile.
• DN: Not a compilation issue, it’s whether it mapps to the right thing in SPIRV. The backendge block must post-dominate the continue. If I’m wrong about this we can re-visit.
• JG: Let’s get some examples and continue working in the bug.

type foo = struct is unfamiliar (#735)

• MM: No new comments since last week. Talked a lot last week about anonymous structs. Would like clarification on why anonymous structs affect this proposal.
• DN: I want to have an expression which constructs a struct of that type and sometimes I might want an anonymous struct to do that without having to give it a synthetic name. Tying something to a name seems unnecessary.
• MM: Can we allow that syntax by allowing the code in your brain to use the syntax of struct {} without a name in it.
• DN: That would be the idea, yes. I guess the point is that’s a new feature which is separate
• MM: Yes, if we want anonymous structs that’s a bigger topic then this. This is just changing how you make named structs.
• RM: Don’t see how syntax for named and anonymous structs would construct. Just seems like a matter of making the name optional in the syntax.
• JG: Grammar is slightly simpler if you never have named structs. If you want named you use the typedef. This ties into if we have anonymous structs. If we have both having named be a combination of named and typedefs.
• MM: Could use that argument for all types and we have types with names.
• JG: Don’t agree with that
• MM: The other point is having a language that uses familiar syntax for authors is more important than simplifying the grammar.
• JG: That’s true but the common way to name structs in C isn’t crazy.
• MM: I’m referring to the way structs in C++, HLSL and MLS and maybe GLSL work.
• DJ: So, no real preference here. Would like to know the cost to the grammar allowing both named and unnamed, as someone who will not implement the grammar. Imagine I’m coming and would type struct foo {}. Which is fine if i’m getting a compiler error but …
• JG: Would actually get a parse error, which kind of sucks. Would get “unexpected identifier - expected { or attribute block”. Not that bad for the grammar. I think a number of us would have anonymous structs and if you have that you can build this out of smaller parts so there is less folks people have to think about. In this case, doesn’t matter that much as it isn’t ambiguous. Just adding a parse node for struct followed by identifier.
• MM: Right one new production and it’s a simple production. Seems like a no-brainier
• DS: It’s fine to me
• JG: I’m ok with it also but a very slight “no”. I think it will be easy to educate people the moment they type the code that doesn’t work. But is it ok to let them have the names too.
• DN: So, I assume this doesn't carry over to arrays as they’re quite different due to other factors.
• MM: You mean Jeffs argument?
• DN: No, Myles argument.
• MM: No, arrays don’t have to be named. This applies to named types.
• DN: What Jeff said, I’m OK with this.
• JG: Happy to have in the name of compromise.
• DJ: Let’s resolve to include. Feel free to argue if a good reason comes up to not include.

Remove is_finite and is_normal intrinsics. (#841)

• DS: This was a matter of me trying to implement them in the SPIRV generation backend. They only exist in the kernel execution mode, which we are never in, so we will never use them. I think we should just put them into the section where we say they won’t be converted.
• JG: It wouldn’t be in this list, it just wouldn’t be translated.
• JG: I was wondering why it isn’t in a compute node? Is it only OpenCL?
• DS: Yes
• GR: Isn’t this a negation of is_nan?
• DS: NaNs are not finite.
• JG: We could slightly redefine it.
• DS: These two cannot translate to what they mean.
• DS: It might be that we put these in a standard library list, but even then we’d have to change these to something else.
• GR: Would we reserve the keywords?
• DS: They are not keywords.
• MM: SDecide on whether or not the std library is the union of all the 3 backends, or not. We should come up with a philosophy.
• JG: My proposal is that generally if there is more support than not (e.g. 2 out of 3 backends), we should have it. Can decide on a case by case basis.
• MM: Agree. I think the barrier to entry for the std lib is pretty low.
• DN: Generally agree too. I would put stuff in there if there is some benefit for an implementation where there is an opportunity for acceleration (e.g. [missed - counting bits?]
• MM: Agree, but might need to look at operations that are exceptionally fast on one platforma and exceptionally slow on others.
• JG: I think for intrinsics it is nice to give platforms the ability to accelerate. You’re not going to be any slower on the other platforms anyway with the polyfill.
• MM: So I think that would put these operations into the std lib, right?
• JG: We’d need to redo the table here… maybe just remove the opcode here? By referencing the opcodes we match the definition of how they work. But we could replace is_finite with the synthesized form.
• DS: We can certainly do that. I’m not sure what is_finite could be replaced by.
• DN: We’ll work that out offline.
• DS: I’ll close the pull request then and open another with the replacement when we work it out.

Add 0/1 swizzle syntax (#732)

• KN: I thought this was already decided to be post mvp?
• DJ: Accidentally had post-MVP milestone removed.
• MM: Seems this isn’t super important for MVP. On other hand, implementation complexity is low.
• DN: Enough concerns about orthogonality. Does have interactions with things like constant folding which is a complicated topic. Would prefer to not have in MVP.
• GR: John had a good point it’s deceptively complex.