Skip to content

WGSL 2020 05 12

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

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
    • 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

  • DN: The Tint implementation is progressing pretty well. The open issues discussed here are not contributing to get to implementable specification.
  • DN: I raised an issue on Friday about the execution order which is important to getting an implementation, for example.
  • RN: WOuld
  • DN: That one in particular isn’t too important because I expect we agree. However, I suggest we look at an example like “Compute Boids” and see what issues are keeping us from getting that working.
  • MM: It sounds like array stride should be on the list. Our Issues are important too. I don’t think we should remove existing issues from the agenda, but adding new ones are good.
  • JG: I agree with David’s point. Maybe we need some project management to help us keep a balance of issues that are blocking MVP vs a finished spec. e.g. what is blocking working code. It might be useful to prioritize. Could be a new column in the project board thing.
  • GR: We don’t seem to have a label for 1.x / future / final spec. e.g. 0/1 swizzle isn’t an implementation or shipping blocker.
  • KN: I think there are not many issues that are post 1.0, but that is one of them.
  • DM: Maybe that could be done with milestones, rather than labels.
  • DN: I’ll take an action to describe what I think blocking implementation means.
  • JG: Should spec editors just work this out offline, or should it be discussed here. i.e. how the prioritization is labelled e.g MVP
  • JG: I think there is consensus. And I think generally it should go into the earliest milestone that people want.
  • DN: Milestones are good.
  • DM: Do we require things to be fully specified before they can go into the CTS? I think we should prioritize everything.
  • JG: It’s not just spec editors that set the priority - it’s everyone. Let’s use milestones.
  • MM: One of the goal that we are sensitive to is the authoring experience for humans, which is reflected by many small issues. We are ok with prioritizing larger issues because it helps progress, but not at the complete expense of the smaller issues.
  • DN: Agree
  • DJ: So by next meeting, we’ll have at least one milestone to help set the agenda priority.
  • DJ: What should we talk about next week? Myles raised the topic of swizzling.
  • DN: We have everything we need for swizzling. (explains)
  • MM: Sounds like it should be on the agenda.
  • JG: I’ll fix up my if break proposal
  • MM: DS’s workgroup size thing.
  • DN: Array stride - explicit layout for buffers. There might not be an issue on it.
  • JG: What about the void type discussion? We could time box it?
  • DN: I don't think the conversation has advanced.
  • DM: It split into two conversations - is it special, and how should it be done? I believe it should be special (you can’t use it anywhere other than function returns)
  • MM: There is some discussion on the loop issue about “what is a simple for syntax”
  • Resolved: We will use the MVP milestone to identify what is important to discuss asap at a meeting. ANyone can add this. It may be because it blocks your implementation, or because the spec absolutely needs it (in your opinion)

⚖️ Discussion

Rule for mixed-signedness operands to integer div, rem, less-than, greater-than, less-or-equal, greater-or-equal (#707) \

https://github.com/gpuweb/gpuweb/issues/707

Remove break if in favor of if () { break; }. (#643) \

https://github.com/gpuweb/gpuweb/pull/643

  • DM: I’m unclear what this is solving.
  • MM: I think I understand what this is about, and I’d like to say it - in case I’m wrong!
  • MM: “it should be idiomatic to write break if because it would be weird to put code between the if and the break, and if they do that, it should be outside the loop in case it provides non-uniform control flow”
  • DN: Good summary. Additionally, it should be wrong to put code in the compound statement after the break.
  • MM: Agreed. But I think that is separate. I think it should be an error.
  • JG: Agreed too. Also add return, kill etc
  • DM: Myles, Are you referring to our uniformity analysis?
  • MM: Yes, our analysis. e.g. you can’t have derivatives
  • DM: Why?
  • RM: I think it is ok because the code will either compile, or fail with a message that isn’t confusing.
  • DM: Do you think it is possible that our uniformity analysis will change to consider those code paths to be uniform in the future?
  • RM: I’ve examined this and concluded that it would be unlikely. It would require looking at non-local code, and difficult to keep the analysis time linear.
  • KN: When analysing the control flow graph, won’t code before the break automatically be considered uniform?
  • RM: It should be done on the AST.
  • JG: One thing that came to my mind is next on the agenda… the appeal to break if is that it makes it obvious that it does not allow code between if and break. One construct I use is #705 which is to not require curly braces after the if. It isn’t the same but it is similar enough and conveys the meaning.
  • MM: That PR in #705 does more than just that though.
  • JG: Apologies for that issue being a little bit different from what I am saying now. But does this little part of it described above sound ok?
  • RM: I’m ok with the idea of no braces for an if break, but haven’t decided on the rest of your proposal.
  • MM: I think if we’re trying to move people from putting code out of this block, then new types of loops make this difficult. If people want to move code from inside the loop in the AST sense to outside, and the loop has two exit points (the loop condition and the break condition), they now need another variable to keep track of where they exited the control flow.
  • JG: True. My understanding is that with multiple breaks, the code between the uniform point and a non-uniform condition test…. [scribe missed]
  • DN: if got to the loop and it was uniform, and then the condition that caused you to exit the loop is non-uniform, then any code executed between the condition evaluation and the break branch is not uniform. You only get back to uniformity when you get to the merge block, .a.k.a. The close brace of the loop.
  • DN: I am happy with what JG is intending to propose. Dan is a bit more strict with this.
  • DN: On the topic of break if is not code that i’m used to… I think people can get used to it. This exists in other languages.
  • JG: The concern from a design standpoint is that it is two grammar constructs that mean the same thing… goes against the idea of only having one way to do things.
  • JG: I’ll fix #705 to do what I say, not what I wrote.
  • DM: The problem you are trying to solve is people who don’t control what goes between the if and the break right? Because if you’re writing the code it will fail to compile. If you get the code from somewhere else, it is harder for you to change, and hence you want a new construct?
  • DN: I just want a construct to exit the loop, without adding extra nesting.
  • DN: I’m fine with JG’s proposal because I just want to exit the loop - no extra scope. As soon as I see braces I start thinking “new scope” and a bunch of other rules. It is the right mindset: I’m trying to pop out rather than go deeper.
  • DM: But a new scope isn’t really bad here - it’s purely a construct. It doesn’t actually exist.
  • DN: I think if JG’s proposal had been made 6 months ago we would have accepted it/
  • MM: No. I think I would have seen it and wanted function calls, etc.
  • JG: I think we’re close. Let’s revisit this next weej.
  • DN: I would like DS’s opinion. I bet he would be against removing braces.

Allow e.g. if (cond) break/continue/return/kill; without brackets. (#705) \

https://github.com/gpuweb/gpuweb/pull/705

  • Discussed briefly above. JG will reword.

Add 0/1 swizzle syntax (#732) \

https://github.com/gpuweb/gpuweb/issues/732

Workgroup Size builtin decoration restrictions. (#750) \

https://github.com/gpuweb/gpuweb/issues/750

  • Needs DS to discuss.

Requiring integral-valued float literals to have .0 seems gratuitous (#739) \

https://github.com/gpuweb/gpuweb/issues/739

  • MM: In shaders people write literals a lot. Most types in shaders are floats. It seems like there should be the ability to use these in tandem without writing “.0” everywhere.
  • MM: We agree that you should not need to unify types. I think this means that the only way to avoid adding the suffix everywhere, then we have to change the default literal to be a float (if there is no suffix).
  • MM: Con: obviously people are not used to this. Pro: They don’t have to type as much.
  • KN: FWIW, GLSL already requires a .0 for floating point literals, which is mildly annoying but you get used to it.
  • JG: You understand it but, in my experience, you don’t get used to it. You just get errors every time.
  • KN: Also, C++ can sometimes incorrectly infer the type of a generic when you do this. It can be a huge pain when using GLM (GL Matrix Math library)
  • DM: Would we want to support an fp-16 seamlessly at some point? If we default .0, then can we support fp-16 later easily?
  • JG: We might have to suffix that type.
  • JG: JohnK’s comment in the bug is useful. He drew the line between implicit and explicit. e.g vec4(8) would be 8.0 because you’re explicitly filling a vector of floats. That narrows the scope of the problem.
  • MM: I wasn’t expecting the conversation to bring up generic literals. I think it would be interesting to ask… for just generic literals could they unify with the statement if it was a function call or assignment - just for numbers.
  • DN: Rob Pike has a nice write-up for how Go does this. I think it is ok to take into account a certain amount of context. _I think this is it: https://blog.golang.org/constants _
  • DM: That is an exclusion from the rule that every expression needs to know its type?
  • RM: Yes, it would be
  • JG: Or, it is an extra rule that allows a conversion to a particular type.
  • JG: I run into issues in other languages where it becomes difficult to propagate the literal because the type system assigns a type quite early. If we could avoid this it would be great.
  • MM: To avoid function overloads, we should do what David suggested: if there are two functions and the type is not obvious - it is a compile error.
  • RM: My concern is describing when the type conversions can happen. Somebody should come up with a legitimate proposal.
  • JG: It’s 10 minutes to go - some good idea here.

🗓 Next Week

Clone this wiki locally