Skip to content

WGSL 2020 08 04

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

:

 Chair
???

:

 ⌨️ Scribe
Google Meet

:

 Location
https://webgpu.dev/wgsl

:

 Specification
WGSL Issues

:

 Open Issues
Marked Issues

:

 Meeting Issues

Tentative Agenda

  • 2020-07-28 Action item review:
    • Apple: Will look into validating grammar on CI.
    • JG: Will update builtin PR to fixup merge conflicts.
    • MM: Updated proposal for #854
    • DN: Find or file an issue related to pointers on #910
  • Reorg WGSL spec (#967)
  • Validation rules for WGSL modules: binding collisions (#889)
  • Add popcount and reverse_bits integer built-in functions (#947)
  • Express popcount, reverse_bits as function prototypes (#968)
  • Move array stride decoration to the struct fields instead of types (#960)
  • Allow struct_decl to have a name. (#952)
  • Interface matching rules (#644)
  • Extern declarations (#883)
  • Introduce Subgroup Operations Extension (#954)
  • Forbid --x (#801)

📋 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

2020-07-28 Action item review

  • Apple: Will look into validating grammar on CI.
    • MM: In progress
  • JG: Will update builtin PR to fixup merge conflicts.
    • JG: In progress
  • MM: Updated proposal for #854
    • MM: In progress
  • DN: Find or file an issue related to pointers on #910
    • DN: That is Myles’s action above.

Reorg WGSL spec (#967)

  • DN: Listed the high level structure and where I’d like it to go. Would like to apply the new structure in a single PR.
  • MM: Looks like a big improvement. Seems to match MSL and GLSL spec.
  • RM: Looks great.
  • DM: I mentioned that we have the ToC in the wiki for the main spec. There is a downside to looking elsewhere because if you’re finding things to do you have to check 3 places. It would be nice if we could have the issues noted in the spec.
  • MM: I like the checkmarks in the ToC. Will we manage that with TODOs or issues?
  • DN: I suggest using TODOs.
  • JG: Let’s put TODO in the title of the section to make it obvious.
  • DN: I’ll put in blurbs without actually writing the section, to make it clear what should go in here.
  • JG: This would be great. Allows us to migrate from TODO sections.
  • DN: I might just merge the PR I come up with.
  • JG: I’m not sure if we need to run it by the editors.
  • MM: I pre-approve whatever the PR is now, so please merge it when ready.
  • Strong agreement with the issue

Validation rules for WGSL modules: binding collisions (#889)

  • DM: Wanted to remind people about why this became an idea. SPIRV does not separate on the type level between samplers. When we convert to SPIRV we need that. It would help if we could identify comparable and non-comparable at the function level so we can identify. If we don’t do this, we’d need a static use at the module level. Without this, some SPIRV that are valid will not be convertible.
  • MM: Disallowing collision at level of static use of an entry point makes sense. Should be able to support dumping lots of code into one module, and being more flexible for scope of reuse makes sense.
  • DM: One counter argument is that if we try to generate an HLSL module out of WGSL then we wouldn’t be able to have those conflicts.
  • JG: Or we’d need mangling.
  • MM: Did we get clarification on how much can be done at compilation time for HLSL?
  • GR: Don’t have an answer yet.
  • DM: Also Metal, what is the situation with conflicting bindings?
  • MM: You can do it, but if it happens then there are complications.
  • MM: No conflict at the module level since these are all arguments to a function.
  • DM: Any objections?
  • DN: Sounds good.
  • JG: I think we have to.
  • JG: The initial post to the issue said there are 2 issues. We’ve agreed to allow the 2nd part, which is binding collisions.
  • DM: The first question is more broad - are we going to validate the module?
  • MM: Question is “would there be a rule that is applied to the module rather than the entry points?”?
  • DM: Yes
  • JG: Other languages effectively defer this to the “linkProgram” step
  • MM:
  • GR: I think this is issue #644.
  • DM: Even if we generate HLSL late, we can still validate the module before that.
  • TR: From DXIL point, this is a library. Binding collisions are not allowed at the module level. I’ll look into it. We validate each entry point (as if used by itself).
  • MM: If you create a library with many entry points all calling a shared function, would this cause code bloat?
  • TR: We aggressively inline things for entry points already. If it is exported then we probably won’t, but yeah, duplication happens.
  • TR: Inlining will happen. Difference is when it happens and whether it happens to all the functions in the module. There might be a benefit to doing it for a module if there are a lot of functions and you use them a lot.
  • GR: I wonder if this is a class of functions where you might want to annotate them to say whether you want this to happen or not?
  • TR: How much of the cost should be front loaded or back-loaded?
  • GR: I’m suggesting throwing the decision to the user. They can trade off memory consumption vs optimization.
  • DN: The API has the option to give an error in either state (pipeline v compilation)
  • MM: Isn’t that in conflict with what DM said earlier? We’ll have to validate everything in the browser before we know the target language.
  • GR: Validation is a bit of a vague term. Some things we can validate early.
  • TR: I’m curious about this validation happening before talking to the runtime. Wouldn’t this mean parsing all the WGSL up front?
  • JG: You could imagine have a WGSL-validator that confirms enough so you can then pass it to a translator that doesn’t have to worry about security (for example).
  • JG: We probably assumed that we’d validate the entry points that are used in the pipeline, rather than everything up front.
  • TR: I guess you could then know if entry points are valid or not, in advance.
  • JG: If the engine knew that things were already wrong, they could hold on to that until pipeline creation time….
  • TR: Surfacing errors as soon as possible seems better. Then they can know which module the error came from. I think it would be nice to have some feedback (e.g. you have an ok module, but only these X entry points were valid). Earlier you catch errors, the easier it is to see where it came from.
  • MM: Compare to C++ - error in any function you don’t get a module.
  • TR: Not quite true.
  • DM: THere are a set of errors you can only detect at pipeline creation time, and not sooner. Is there a reason to NOT do other error detection at “compilation” time?
  • GR: I don't see any reason not to.
  • MM: For WSL (not WGSL), we had two parts. The compilation part was the one catching the errors. The MSL generation part would never produce an error.
  • JG: If we have to do all that work up front, I think DM is asking if some errors could go into the earlier step. Waiting until pipeline creation is the most conservative part, but maybe we can avoid that.
  • MM: I see two options:
      1. Dictate where each error could occur
      1. Allow errors to migrate between steps
    • I suggest option 2.
  • JG: I advise against option 2. People will assume portability of where errors occur. e.g. assume a “link” will succeed because a “compile” happened. In WebGL we defer things to the later point where we can know for certain that everything is ok. Specifying when the errors will occur will avoid portability issues.
  • DN: I am strongly with Myles’s option 2. I think that a failure to compile will also be caught at the link/pipeline stage too.
  • JG: For WebGL, we advise people to not bother checking compilation step until you see a link failure (at which point you check the compile log). If we can’t guarantee that it won’t always happen until the pipeline step, then we should make it only happen at that step.
  • DN: I disagree. e.g. I’d like to check at shader module creation time if possible. As long as both stages have a way to return errors, then i’m happy.
  • TR: I agree. It would be nice to have a single point to get errors from, but this is ok. Perhaps validation at shader module time could have metadata to tell us what features are available?
  • MM: That’s coming up on the agenda - subgroup operations. Assuming you are calling it correctly, we should allow those calls at compilation time, but the error happens when you use it.
  • TR: I am receptive to the fact that you don’t want errors happening in different places on different platforms. If you had a robust way of finding out which errors occurred where…
  • TR: Maybe an API on the module that allows you to check the valid entry points?
  • agreement - collisions in bindings are allowed in the module (but not in static use of an entry point)
  • Action: DM to file an issue on module validation

Allow struct_decl to have a name. (#952)

  • DN: Both myself and MM have already approved this.
  • MM: We’ve already resolved on this too. Not much to discuss.
  • Approved and merged

Introduce Subgroup Operations Extension (#954)

  • DM: I would like DN to make a single point where we can discuss subgroup operations. It’s confusing to follow all the points of discussion.
  • DN: I thought we agreed not to do this for MVP. I only saw #954.
  • MM: This might end up as an extension. Q is whether we do the extension now.
  • JG: I think we should concentrate on the MVP things here. If there are interested bodies, they can work on it but not necessarily discuss here.
  • MOD: The last point that blocks this extension in divergence (but the only operation is subgroup broadcast with an invocation index). If we remove the indexed broadcast we can make progress, we already don’t have shuffles because HLSL doesn’t expose them. Helper invocations is not a concern because the extension, as stated in OP and past discussions, is compute only.
  • JG: This seems good. I think you should summarize all this into the issue and make a proposal for what you think will pass. But I don’t think we need to take the time now.
  • MM: Or, tell us why we need this for MVP.
  • MOD: I would like to get DN’s opinion on the divergence.
  • DN: Lots of sharp corners here. e.g. articles on AMD compaction assume their compiler, but nothing in the language guarantees this. Adding subgroups in particular … MISSED … we’d need much strong guarantees from the underlying apis and we don’t have them
  • Scribe/Dean had connection issues during this - sorry
  • JG: Philosophically, it’s ok for an extension to be specific to a single implementation but we’d like to avoid that. We’d be motivated to accept something that works in multiple places but is also useful. Factors are: ease of portability, ease of implementation, etc. Start small and we can work from there.
  • MM: Firstly, I’d like to propose that our extensions have the goal of working on at least two APIs (might change that later). I suggest avoiding vendor specific extensions for now. Secondly, DN, if we go with subgroups only allowed in uniform control flow, makes them less useful but possible. Does this lessen your concerns?
  • DN: Does lessen them, yes. But some fundamental things still unaddressed. Such as forward progress guarantees.
  • MOD: e.g. Wave active sum, an implicitly active operation. Why is that a problem?
  • DN: I don’t know who is in my wave. It can spontaneously change based on some simple-looking operation that has some complex multi-invocation implementation that the page author can’t apparently see. And no backend API has strong enough guarantees to make pair-wise reconvergence occur on demand. Sometimes the divergence/reconvergence can be affected by the state of the machine that are hard to test for in a CTS.
  • DN: I am worried about repacking and spontaneous invocation. There isn’t much in any abstractions that guarantees reconvergence.
  • JG: Running out of meeting time. Let’s get this discussion moved into the issue.

Next Meeting

  • DN: I think we can do popcount/reverse_bit offline
  • JG: I suspect the forbid --x will either be quick or long, so let’s do it.
  • JG: I think we’ll want to talk about interface matching rules - ties into validation for module v pipeline.
  • MOD: Would appreciate some eyes on the subgroup issue.

We will have a meeting next week even though WebGPU is not meeting.

Action Items

DM: Open the issue on validation locations

Clone this wiki locally