Skip to content

WGSL 2020 04 28

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

Quick topics that might be resolved before the meeting:

Discussion topics:

📋 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 [email protected]

❓ 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

  • DJ: Github project used to define the agenda. Add items to the column in the project and order as desired. If anyone knows how to associate a tag to a column that would be beneficial. There is a script in the repo to generate the agenda from that list.
  • MD (chat): GitHub Actions probably can handle that

⚖️ Discussion

Add bit-complement operator ~ (#727)
https://github.com/gpuweb/gpuweb/pull/727

  • DM: Rust feedback was it uses a lot of different symbols. Less symbols makes the language more uniform and easier to read. In this case, using the same symbol the semantics are preserved and can use ! for both OpLogicalNot and OpNot.
  • DN: Was just following C. C has implicit conversion of int to boolean but we dont’ have that in WGSL.
  • MM: So, we’re baking in no-implicit conversions forever. I’d be ok, but want to be explicit.
  • DN: Backstory, GLSL ES has no implicit conversions but desktop GL does. Someone found them useful ….
  • KN: Doesn’t completely prevent, just becomes an overload of !. In C ! is only a boolean, and int is coerced. In our case, we have an overload for ! so we don’t coerce. You’d have to explicitly cast beforehand if you wanted the other option.
  • MM: So how do we progress.
  • DN: Drafted for familiarity. But don’t care all that much
  • JG: Have weak feelings it should inherit what most programming languages do
  • KN: More reading even if we don’t have type coercion. LIke the different symbol.
  • DM: Symbol doesn’t overload the semantics. Thinking of boolean as 0 or 1 the semantics are the same
  • JG: In my head, ! for an int is a narrowing operation
  • KN: Same symbol for both would prefer ~ as the standard semantics across languages maps, but ! semantics don’t map. Except for rust.
  • JG: if ~foo is a little weird, but know what it’s doing.
  • DN: Plug for unless …..
  • KN: Both symbols is slightly more readable.
  • DM: Aren’t trying to develop something close to C. Going from first principles ot find what is best for language and semantics. In other cases we don’t appeal to C, in this we do. Something that a compiler can tell you if you’re wrong
  • JG: Don’t know of any other language that does for ! what rust does. Every other language with an op for bools can narrow ints. True in most languages, not just C. Maybe the case that Rust is the odd one out here.
  • DM: Does it imply implicit conversion or narrowing
  • JG: Yes, but I care more about narrowing ints then converting ints to booleans. Would be a pain if you had to convert to bool everywhere.
  • DM: So, ! would work as an int narrower so would work in both ints and bools?
  • JG: No idea, just saying what I”m used too
  • DM: Without narrowing that argument doesnt’ apply
  • JG: Shoudl determine if we narrow
  • DM: Should have no implicit conversions. Would like to hear strong case
  • JG: All other programming languages have them.
  • DM: Not all of them
  • JG: Basically. We have errors for int narrowing as that’s a hazard. For bool narrowings we don't’ warn as it is not’ a hazard. Is fairly well entrenched.
  • DJ: Suggest opening an issue on if we do narrowing. Then hold #727 open on that issue. DM Can you open the narrowing issue?
  • DM: We should do implicit conversions in general and narrowing is just one case.
  • JG: Characterize separately as narrowing and implicit bool conversions. Technically related but have different opinions.
  • DM: Not going to file an issue on narrowing but JG you can if desired. Will file implicit conversions.
  • DJ: One from DM one from JG both blocking #727
  • MM: It’s valuable for this group to say there is a bit complement operator regardless of the characters pressed on keyboard
  • JG: Yup we need that.

Describe switch statements (#713)
https://github.com/gpuweb/gpuweb/pull/713

  • DN: Current draft has it as valid to fall through the last statement. Dan asked if it was an error
  • MM: Seems more like a programmer bug then anything. So we fall on the side of it being an error. Code gen can just not gen that code.
  • RM: If we figure out it’s useful we can add it, but we can’t go from allowing it to banning it. So, start with it as an error.
  • DN: That’s all fine by me, what does swift do?
  • MM: Don't know.
  • DS: So, we make that an error and thumbs up?
  • DJ: Yup. Resolved.
  • MM: It’s illegal to have something in the switch before the first case, right?
    DS: Yes.

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

  • DJ: Proposal from David, thumbs up from Myles. No other comments. Sounds like universal support
  • DM: Anything to worry about? Maybe DN knows, and doesn’t tell us.
  • DN: Like this because it lets me write in the source language in all the cases. Like NaNs of different flavours. Many different bit representations which map to nans which get mapped differently and want to have all the weird cases
  • MM: Good idea as long as we don’t remove the other ways.
  • DN: Yes. This is independent of any suffixing on literals to indicate the type. If it’s f16 or f32. C99 floats are awesome.
  • DJ: Ok, resolved.

Issue #715 - proposal: permit redundant as-casts

  • DN: Grammar allows it. As cast is bit cast between types so it seems good to be orthogonal to allow as cast of the same type. Not something in SPIR-V but seems like a good feature.
  • DM: The use for the as on a trivial cast is on type definitions when you don’t know the type. We don’t have type aliases so you always know, it’s not the chain of types you need to look at.
  • DN: The reason this came up is the translation of SPIR-V -> WGSL have to handle OpSDiv where the operands can have mixed type and have to insert an as to rectify the types. Then on the result have to make sure the result is the right type. But, I want to compose those in a context free manner. Just seemed like something to not worry about.
  • DM: So, HLSL -> SPIR-V does care about and if it’s redundant it has to not issue the instruction. Why does SPIR-V disallow
  • DN: Don’t know, it’s a rule. Would be seen as a generator error, the redundancy would be seen as the tool can remove the redundancy. But as a human authored thing can be more forgiving.
  • MM: I think the difference to fallthrough is I don’t think redundant as cast is a programmer error. I’ve added redundant casts for readability but never did a redundant fallthrough for readability
  • DN: I’d buy that and like orthogonality.
  • DM: maybe we’ll have type aliases
  • DS: THere are type aliases.
  • DN: SPIRV has a uniqueness constraint where numeric types must be unique, but that may be something we can resolve.
  • MM: SPIRV -> WGSL wouldn't do type and WGSL->SPIV collapses to its root node.
  • DJ: Marked resolved.

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

  • DN: I think the answer is no. I’m always defensive and put them in but consensus is no, which is standard semantics in C. If no default and no cases then don’t execute the switch
  • JG: Like an implicit default that’s empty
  • DN: Implicit default with a break in it.
  • JG: Right. From a tooling view like a linter to tell me if the switch is not’ exhaustive. Do like to have but could be a linter error on top of our work.
  • DN: Would go hand in hand with the enum issue which Myles file.d
  • MM: Enums are a little different, can discuss later.
  • RM: They are connected. Without enum, requiring a default case would be nice but not really required. Most languages more recent then C including ML like languages including Rust. Pattern matching on something enum like requires explicitly covering all cases which I think is a good thing. Makes refactoring easier and safer. While it could be the linter could be something we easily add to the grammar and spare a lot of trouble to the people who don’t use the linter.
  • DM: We don't have enums.
  • JG: Would be an argument for it to be related. In C++ linting, switching on a value type doesn’t care if there is no default, but if used on an enum it will warn. Standard in C++ but don’t know about other linters. If you have that for values and want to go to enums and want enums to be required to be exhaustive it’s weird. Isn't’ a ton to ask for folks to put in a default to be clear that if nothing is to happen that nothing happens. If we require a default now, it isn’t unreasonable to require it if you haven’t exhausted it and we can change it later if folks think it’s bad.
  • KN: For types now you’d always need a default as you can’t exhaustively have all the values.
  • JG: Can’t exhaust a uint32
  • TR: Could do it on bool. HLSL requires a default case. You could generate it though.
  • JG: Interesting for prior art
  • KN: Prior art from ML languages and swift is to be exhaustive. It’s less useful without an enum but it’s a good feature. Nice to require for now and can take out later if we don’t want it.
  • JG: I agree
  • RN: Agree as well
  • DN: Fine by me.
  • DM: The exhaustiveness comes with rich pattern matching. If it’s this range do this and that range do that. We don’t have that here and even with enums will open the question of what type of enums do we have. Do buy the argument we can require now and remove later. Not confident we’ll need enums.
  • DJ: With that slight hesitation and everyone else agreeing we accept this.

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

  • DS: We’ve gone through this a few times. Thanks to Robin for writing up.
  • DS: Using loop continuing can be confusing, but while continuing is less.
  • RM: I don’t quite agree. I think they’ll have to look up what “continuing” means. It is its own thing and orthogonal to the loop itself. The “continuing” is what you do on the back edge. I don’t see a reason for the two to be connected.
  • RM: I don’t see why the existence of “continuing” be connected to the loop keyword being “loop” or “while”. I think they are two different concepts. I don’t see why the choice of either would confuse people - it will be the “continuing” part that is confusing.
  • DS: I feel like the confusion will more likely come from something that looks like a known “while” loop but isn't
  • DN: In the for you have 3 clauses. To de-sugar the “for” into a “while”, you can move them fairly easily.
  • DS: I think that works - if we pick “while”.
  • MM: Are you talking about a tool doing this?
  • DS: In the spec I would say “A for loop is exactly the same as setup, while loop, continuing”
  • MM: Good
  • JG: I’m fairly opposed to complex statements in the “for” expression, but if they are simple I’m not as opposed.
  • DS: Right, this is not adding comma operators. Just a single statement.
  • MM: To be clear, this is replacing “loop”?
  • DS: Yes, loop becomes while.
  • DN: I object to that. I have seen examples of exit clauses that are quite complex. I want loop and continuing to stay.
  • RM: I think that tools would still have a loop-like construct.
  • DN: I see the argument. In that case I would like us to consider “unless” again.
  • RM: That might be ok.
  • DJ: Let’s not discuss that right now.
  • JG: [missed]
  • DS: What if we had “while” without a conditional, and “while” with a conditional?
  • JG: That would be a bit confusing. I found “loop” to be nice, and not confusing.
  • DM: I think we need more information from shaders, to see what they do.
  • JG: I don’t think we can get actionable data from that. Because the presence of the constructs will affect how they wrote the shaders.
  • DM: It could tell us something, e.g. if they use “while (true)” a lot or if they use “for” a lot.
  • JG: I disagree. If people have a “for”, they will use it. The reason I recommend against having it is that it would not be onerous. I don’t think seeing it in other people’s code would change that.
  • JG: I think we’re at the point were the proposals are:
    1. loop without any desugaring for “for”
    2. Loop with for desugar
    3. For desugar to a while
    4. While without any desugaring for “for”
  • JG: That order is my preference
  • RM: Preference is c, b, a. [said before d was added]
  • RM: There might be another option: while without desugaring “for”
  • DS: My preference is loop with a for desugaring.
  • MM: I gathered a corpus of ~2000 HLSL files from GitHub about a year ago. I just did a quick search… 5. 7.2% are “while true” 6. for (;;) is only used once
  • JG: That doesn’t seem surprising to me. I feel like that says we could have just “loop”.
  • DN: If this was networking code I would have expected more infinite loops. In shaders I am expecting fewer.
  • DN: Joke about running an infinite loop in a shader: https://twitter.com/matiasgoldberg/status/1254450769010536449
  • DJ: We will enumerate these options in the github issue so that we can give opinions.

🗓 Next Week

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

Syntax for "the zero value" for bool type, numeric types, and compositions of them (#685)
https://github.com/gpuweb/gpuweb/issues/685

Remove break if in favor of if () { break; }. (#643)
https://github.com/gpuweb/gpuweb/pull/643

Define the void type (#712)
https://github.com/gpuweb/gpuweb/pull/712

Clone this wiki locally