Skip to content

WGSL 2020 04 14

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

:

 Chair
Mehmet Oguz Derin, Dan Sinclair, Damyan Pepper
  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.

:𐰆𐰍𐰔 :

 ⌨️ Scribes
Google Meet

:

 Location
https://webgpu.dev/wgsl

:

 Specification
WGSL Issues

:

 Open Issues
Marked Issues

:

 Meeting Issues 


## TL;DR;
  • FAQ changes were accepted with notes for two changes.
  • Lexical scoping discussions are ongoing. May require annotations for SPIR-V roundtripping, waiting on more information on those annotations
  • Waiting on the c-like declaration order, looking for more developer feedback
  • Discussion around entry_point keyword. Will be more follow up on the issue showing examples of how this could work when attached to a function.
  • FP16 is agreed to be an extension
  • Discussion but no agreement around break if.

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

⚖️ Discussion

🔗 Issue #687 - WGSL FAQ

  • JG: The target of the FAQ won’t know how the group is setup, so phrasing for the target of software development can be confusing
  • RM: It is reasonable to rephrase the sentence to clarify the difference
  • MM: Maybe it would help to change community group to standardization group
  • JG: That could help. Does anyone have material concerns?
  • RM: Saw comment by Dzmitry but haven’t had a chance to handle yet. (... missed this …). For SPIR-V will move the faithful down
  • DM: So faithful won’t be defined by round-trip anymore?
  • MM: Concept of faithfulness is different from round-trippability. You can be faithful being able to round-trip.
  • JG: I think that’s where we get to canonicalization concept of DN. That’s what I use to think about faithfulness.
  • DN: Agreed, for this FAQ, we don’t need this anymore in this FAQ.
  • DM: Faithful is used for roundtripping of SPIR-V, what about MSL and HLSL which we don’t plan to roundtrip.
  • GR: Do you mean HLSL or DXIL?
  • DS: For Chrome, we have to target both HLSL and DXIL.
  • DP: We can say efficiently digested by DirectX
  • GR: Silence means this change is not contentions?
  • DN: Sounds like an improvement to me.
  • JG: DM dropped from the call. Sounds reasonable to me, may not want to exhaust the language space of all the languages we ingest. Haven’t thought about what it means to target DXIL instead of HLSL
  • MM: That would probably affect the uniformity rules.
  • GR: Talking about DXIL vs. HLSL?
  • RM: Haven’t seen documentation on the uniformity rules
  • JG: Haven’t been thinking about DXIL so don’t know if we can just substitute HLSL for DXIL as we haven’t thought through what that means.
  • GR: I don’t mean to replace it everywhere, just to replace it at the top
  • TR: Yes, at the top next to faithful
  • JG: .
  • GR: I think it is harder to convert to HLSL
  • MM: I think this is a decision point where we settle on HLSL or DXIL mainly
  • DP: We care about Direct3d
  • JG: Just to clarify, the text says to/from SPIRV and to HLSL and to MSL. So, as long as that careful reading is ok, then we’re good.
  • DJ: Noted this as a task
  • JG: May want to bold that fact.
  • GR: What about as doing with 2 bullet points for SPIR-V, one for to and one for from.
  • JG: DM had a great point about we get just one release of the FAQ, people won’t come and read it a lot if we update it
  • DN: It’s in GitHub and history is explicit
  • JG: My point is that people will read it once
  • DN: That’s fair, they might anchor on it
  • JG: I’ve approved it
  • DJ: I’ll add the label with the note for two changes.

Issue #559 - Lexical Scoping

  • JG: Seems there is rough consensus on lexical scoping.
  • DN: I want to make it work with round tripping. Maybe we can add annotations to code so that becomes feasible.
  • MM: Will these be visible on source language?
  • DN: Yes.. Don’t want to depend on on Mem2Reg as that changes programmer intent
  • MM: What about going to other languages?
  • DN: You just ignore them.
  • MM: So they are optional, not enforced?
  • DN: They are just hints.
  • MM: So that can even be the case for SPIR-V.
  • DN: Correct.
  • RM: .
  • JG: .
  • DJ: So we are saying that issue is accepted?
  • DS: Would it be acceptable to update the spec accordingly?
  • MM: I am not OK with accepting whatever DN makes
  • DS: No, this is just about separation of concerns
  • DN: This is just about having an agreement on direction rather than a full solution
  • JG: If we can’t figure out how to figure it out we won’t have lexical scoping.

Issue #677 - C-like declaration order

  • MM: This is a reasonably simple issue, there have been at least two cases where we talked to developers who use #define to generate GLSL and HLSL from the same source
  • DN: That depends on the source you start with. Have seen Rust compiled to SPIR-V and Haskel DSL. There is bunch of things coming up which can have this issue.
  • MM: One fo the lookahead issues is the * in C, which we don’t have in WGSL.
  • JG: A fan of type inference. Having non-c-like declaration makes it easier to have optional types, to me. Would like optional type decorations, types deferred by default. That would be the main workflow. C-declaration order would have to do something to allow that inference. Won’t have the same #define ability quite as easily. Even with a C background and new-ness to rust, like the Rust type syntax better.
  • MM: Was hoping for something more rigorous
  • JG: Easier to parse the next character when you know what the thing you’re looking at is. True for computer parser and human readability.
  • MM: One possible path forward is to not take any action but talk to more developers to see how valuable this proposal is. Do hear what you’re saying. Maybe just leave this open and come back to sometime later.
  • JG: Ok, will comment on issue.

Issue #662 - entry_point_decl should be an annotation on the function

  • MM: Right now, SPIRV decorations, in SPIRV you can decorate a variable saying this is a variable, this is a variable that means GroupID, that lives on a separate line. In WGSL, this works in single line with square brackets. This proposal does the same for entry point. It would be better if this was placed next to the function signature. This proposal doesn’t reduce expressibility, just replaces where things get set.
  • DN: One place this has issue is a compute shader with a workgroup size on it. In SPIR-V the workgroup size is annotated on the entry point. You would have two entry point functions in WGSL.
  • MM: Another solution is to let the annotation take a list.
  • DN: If I had a workgroup size a,b, I’d add those annotations in a list and I could call that function with two workgroups?
  • MM: Yeah, function would be called “miles”, annotations could be a list: “expose as ‘foo’ with workgroup size alpha”, “expose as ‘bar’ with workgroup size beta”
  • MM: The workgroup size has to be associated with the entry point name. So, you want them together either anyway.
  • MM: Example:
    [[ expose_as: "entryPoint1" workgroupSize: [1, 2, 3], \ expose_as: "entryPoint2" workgroupSize: [5, 6, 7] ]] \ compute void foo(...) { ... }
  • DN: Concerned that this could become a new sublanguage…
  • KN: … and become unwieldy if it has more than the subgroup size.
  • MM: I don’t think it would be that tricky - there would be defaults
  • MM: The default common-case will look like workgroupSize: [1, 2, 3] compute void foo(...) { … }
  • JG: We’ll follow up in the issue.

Issue #658 - FP16 support

  • MM: It increases performance, decreases bandwith and memory footprint
  • DN: Not up to WGSL
  • MM: JS doesn’t have FP16 type
  • JG: WebGL does have FP16 resources
  • KN: There are all sorts of resources (vertex data, texture data) e.g. FP10 mostly for fetches that get upconverted to whatever the shader supports (fp32?)
  • DS: Does this need to be a case where on WebGPU side we need to say this impl. supports FP16 or something we can delegate to WGSL?
  • JG: We lack hardware support on all targets. So, for the core language we say 32 what is spec’d and 16 is an extension
  • RM: I can see the performance benefits of relaxed precision but more concerned about the portability. Some will get benefits on places where hardware support is provided and possibly decrease on others.
  • KN: Concerns me too, but while it isn't’ universal to have Relaxed support as long as we take FP16 to mean relaxed on all platforms we can, then the porting platform is reduced.
  • DN: Doesn’t sound minimal . Worked on platforms where it was hard to figure out what was going on. If we want this in the first version, will delay the first version
  • MM: Our discussions with the Metal team was the exact opposite. That we should definitely include this.
  • JG: Was metal discussion on FP16 or Relaxed?
  • MM: Those are the same on Metal
  • JG: Those aren't the same on other platforms.
  • KN: Relaxed could be either FP16 or FP32
  • JG:Could get different behaviour on platforms when using Relaxed
  • MM: We’re agreeing
  • JG: Can't’ get guarantees on the availability
  • MM: What I am saying is this should be part of the first version, fine if it is an extension. We want some way to describe 16bit computation in Metal.
  • KN: In favour of fp16 over relaxed
  • TR: Second that. MinPrecision in HLSL has been problematic. How do you read them as you don’t know if they’re 16 or 32 bit. Don’t get reliable behaviour over hardware. Going with explicit in the figure, have a switch that says min isnt’ supported anymore.
  • DN: Vulkan went that way already, either 16 bit or 32 bit. MediumP and LowP map to Relaxed precision annotations, which store as 32 bits but can calculate in various precisions. Encourage folks to Fp16. If we do this, want both storage and access of 16 bit. In vulkan those are split and different platforms turn on different ways. Now in agreement provided this is an optional feature.
  • JG: Sounds like consensus on an optional FP16 extension.
  • TR: Sounds good.
  • DN: Won’t have universal support for 16bit quantities on IO stages between vertex and fragment shaders. Those may have to be 32 bit to get maximum coverage. Though, maybe solved by the time we get all this out the door.
  • TR: Can that be solved at the backend? Have limitations which say they can be stored in 32bit, can’t pack values in so they don’t fit into 32 bit, then the backend can expand if they have to be.
  • DN: Probably true, would depend on how you count locations.
  • TR: Basically what D3D does
  • MM: Even for 16 bit interpolants?
  • TR: 16 bits interpolants could be 32 bit in hardware and switch to 16 bit in shaders.
  • MM: Pretty good argument it’s OK for us to do.
  • JG: Can’t eliminate portability concerns, but can make them small
  • DN: Do we want a QuantizeF16 like SPIR-V has? Truncate on mantissa and saturate on the exponent.
  • MM: Is there different behaviour to casting to f16 and back?
  • DN: No. Useful if we don’t know if 16 is available or not, useful for weird bits. Probably don’t need instruction but want to keep idea around
  • JG: Can you file an issue?
    DN: Sure:
  • JG: Sounds like a builtin
  • MM: Link to it from the standard library issue.
  • MM: So do we have consensus for a single f16 extension which does both internal storage and computation.
  • JG: Sounds like yes to storage, yes to computation, no to interpolation.
  • MM: Sounds good to me.
  • DM : Sounds good.
  • JG: Resolved.

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

  • DM: Asked what problem with if break is, and David said there might be confusion issues if the user wants to add things, I don’t think there would be user confusion. In Native this would be issues around the uniformity. If something goes wrong users would be instantly aware something went wrong.
  • DN: it won’t be instant, it’s a weird corner case. Want to make it so you can’t have statements after a break. Want to make that the case for break and continue. Would also prefer if there were no statements before the break.
  • MM: then how would you write code where you want stuff to execute before the break?
  • DN: you capture the condition in a boolean value and check it in the break if.
  • JG: the concern then is that this is something you could construct, but we’d like authors to be able to surface that they don’t intend to do that, and that adding something before the break in the branch will change things. This would allow for better expressment of content. My concern is that if “if break” is a best practice, then you can have that without putting it in the language. I understand the desire to have it more obvious.
  • RM: Don’t really understand what the issue is. Is it purely a uniformity issue?
  • JG: it’s an ability to express uniformity. I see it as someone writing code keeping uniformity in mind may choose to use break if instead of unconditional break because it makes it clear to someone who’s not as away of the concerns that they can’t modify the code to insert code before the break without having to restructure it.
  • RN: What does it mean for it to be out of the loop? It’s not in the control graph cycle but what impact does it have on anything.
  • JG: the difference is that if you have one unconditional break in your loop and you have code executing before that then all the prior code could be in uniform control flow...I’m not sure if it is ...
  • MM: No it’s not.
  • JG: OK. My opinion is still if (foo) { break; }. Especially if we omit the braces which is a different contentious issue.
  • KN: if the size of the loop is static and you do something unconditionally before a break while it is uniform, then it happens to uniform control flow. Our more simplistic rules will say that we don’t know if it is uniform.
  • RN: Presently they will say that if you are within an if, for control flow to be uniform the if condition must be uniform. Same with a loop. So, if there is a number of iterations it’s clear if it’s a static uniform condition. So if it’s done in a simple way the compiler can see into it may be uniform.
  • GR: Are function calls allowed in conditional statements?
  • ?? Yes
  • GR: if you’re trying to not allow anything in an if block before a break, what would stop anyone from issuing a function call that’s effectively adding more code before the break.
  • JG: You can lead a horse to water but you can’t make it drink. You can do that. Context for the concern is that these things are expressible. You can do things that are non-uniform and risky so we have to support them so having function calls is required.
  • GR: ok - so the intent is not to prevent people from doing something stupid, but to make it harder.
  • MM: Before we end, encourage dneto to write a down proposal on dis-allowing statements before or after the break in the conditions.
  • JG: I might have a different, but related issue here.
  • DN: ?
  • MM: New proposal is stronger then the original one as the new requirement does not allow statements before the break
  • JG: I think we weren’t removing the ability to put things before the break. Rather we were making so that if you had “if() { break} ” it’s treated as “break if ()”.
  • MM: That’s already true, there is no difference
  • JG: The difference is the expressiblity in the written language is clearer if there is a specific syntax. It’s already technically possible.
  • (meeting ended due to time)

Issue #569 - Consider adding sugar for familiar loop constructs

🗓 Next Week

Clone this wiki locally