Skip to content

WGSL 2020 07 14

Jump to bottom
François Daoust edited this page Dec 2, 2020 · 1 revision
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

  • 2020-07-07 Action item review
    • Microsoft on #644 (GR: Indication of timeframe for feedback)
    • David on #572 (PR #886 I think)
  • Open PR review
    • Rename kill to discard. (#918)
    • Add text around entry point function. (#906)
    • Describe module constants, including pipeline-overrideable (#886)
    • Add stride array decoration. (#910)
    • Explicit layout needs more than Offset: ArrayStride and matrix attributes (#773)
    • Adding textures to the spec. (#909)
    • bool equality (#913)
  • No explicit grammar for decorations (#689)
  • C-like declaration order (#677)
  • Vertex and Instance ID and base ID builtins. (#901)
  • Use brackets for array types (#854)
  • Validation rules for WGSL modules: binding collisions (#889)
  • Constant propagation (#905)
  • Interface matching rules (#644)
  • Extern declarations (#883)
  • Forbid --x (#801)
  • Invariant qualifier (#893)
  • Support #line directive (#606)
  • Function overloading (#876)
  • Shader portability (and performance portability). (#895)

📋 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-07 Action item review

  • Microsoft on #644 (GR: Indication of timeframe for feedback -- July 28th)
    • GR: Need to determine a broad plan of what happens if outputs from one stage are not used in a following stage. We have some fallback plans. We don’t quite have the complete information yet.
  • David on #572 (PR #886 I think)
    • DN: Yes, this PR addresses the action.

Rename kill to discard. (#918)

  • DJ: From last week. Are we ok?
  • JG: There is a difference between discard and fine grain discard but we can call it something different.
  • MM: Sounds good.
  • JG: Merge
  • DN: So does discard mean kill. Does it follow GLSL semantics
  • JG: Yes.
  • DN: That is more easy to implement across platforms. Raised questions around helper implementations and terminations nad how that causes issues but we aren’t going down that path so not need to worry about it
  • MM: Uniformity makes that not happen
  • DN: Not true, not where you do the derivative, but if you terminate
  • MM: Right, if there are 2 threads, one exits and the one next to it doesn’t then those are different
  • DN: It’s about if the live one ever terminates.
  • JG: Like if you’re writing to a side buffer? Can you still do things after you discard?
    DN: A and B. A discards, B keep going. A turns into a helper. Can have one in an infinite loop. A must know when B exists. In some impls, if they all become helpers they could run forever, some impls will terminate. Has bitten people
  • JG: Not sure what helper does
  • DN: Continue to execute in order to help others in the group do derivatives. Don’t know when that derivative will happen so keep going until the other thread exists. Need a way to detect others have exited and not sure what happens if all helpers
  • MM: Do we need to spec? Say on some impls it will kill as a helper some other impls it wont?
    DN: We don’t have to demote to helper, so not an issue for now.
  • MM: { discard(); while(true) {}}
  • DN: If all invocations run, some impls will all demote to helper and some impls will get killed by the OS.
  • MM: Maybe that’s OK for WebGPU
  • DN: Could be, but we aren’t going down that path as we’re going with GLSL kill. In WebGPU would never get to that while loop.
  • JG: That’s GLSL semantics
  • DN: Yes.
  • MM: Confused with last sentence.
  • DN: In your example, in webgpu will never execute while as it will exit the function and entry point
  • MM: For impls with native shading languages which turn those invocations into helpers, the compiler to make that shading language has to work to make sure that future work doesn’t happen.
  • DN: Or you detect and by pass infinite loops. Also avoid other side effects.
  • JG: Could you polyfill this by having top scope early exit?
    DN: Could set flag at module scope to say i’m out, Discard sets flag, every function checks flag and early returns.
  • JG: Sounds like 2 points. Choose name of kill vs discard. Sounds like on border of needing an investigation for where this needs to be polyfilled
  • MM: Biggest concern is doing the transformation DN described means every function call becomes a branch. Branches are usually consistent so not so bad, but worried about perf. One option is we mandate one behaviour, helpers don’t exist. Anything that would turn into a helper, the compiler makes it behave as if it doesn’t exist. Another option is make this undefined. There maybe helpers, there may not, if you use them your shader is wrong but not a compile error
  • DN: Not worse than what’s in the wild.
  • JG: Might be a good investigation
  • GR: Knowing how helpers work in the wild, it’s a low bar
  • DN: Has caused issues for people porting games between platforms
  • RM: Concerned by the perf if we don’t spec something. Not clear for performance which APIs have which behaviour. Which ones would we have to do the branch return trick.
  • JG: Should have investigation to write this down
  • DJ: Accept PR with a note to do an investigation? Jeff can file an issue and we can link that to the spec.
  • DN: Done experiment of polyfilling the other direction and it’s more distasteful. Will write down thoughts.
  • MM: Say you turn kill into a super return, invocations that hit the kill will be divergent from other threads. So, those helpers no longer help as they can’t run derivativeS?
  • DN: That’s correct and what uniformity analysis was saving us from.
  • DM: We have helper threads that appear when we discard and there are main threads that keep going. When the main threads finish execution is there no logic in the scheduler or hardware to shutdown the wave? All the threads are done or helper?
    DN: System dependant. Normally helper invocations are created by the system rather than the fragments. The discard transforms the programmer invocation into a helper one which is why it’s extra complexity. The system generated helpers could be easier to have managed to take down when the other threads are taken down. Nvidia has support in hardware to have threads sense when other threads are demoted and have them all die but not universal.
  • DM: So, could be a platform where a wave is only helper threads and it still waits for them to finish
  • DN: Yes.
  • DM: Oh god.

Adding textures to the spec. (#909)

  • DS: Two open issues
    • texture_sampled_1d vs texture_1d
    • Texture_ro_1d vs texture_1d<read>
    • If we do the <read> do we do <depth> or keep depth_1d
  • DS: I went with the very explicit one in the PR, but that might be annoying. I don’t mind which one. If we went with the explicit naming would we keep the “depth” suffixes?
  • MM: Last time discussed, someone wanted to investigate if we need 3 distinct types or 2 distinct types. Ro vs Rw vs sampled.
  • DS: Looking at the spreadsheet that Justin made, it looks like we do because you can’t use them in the same place in all platforms
  • MM: textureLoad can only be done in a load, etc?
  • DS: Yes, didn’t do write yet
  • DM: The problem is that we’ll have RW textures as an extension because they are supported. Having a separate type seems annoying. Better as a flag.
  • MM: WHat is the difference between a new type and an access flag?
  • DS: Nothing
  • DM: You don't need to repeat them in the spec.
  • DN: Whether the validation rule is checked by type checker or separate rule
  • MM: We may, in the future, want to use angle brackets for language features. So overloading them now may be unwise.
  • DM: We already use them, not about introducing the angle brackets. Used for types
  • MM: That’s true, but the distinction between vec4<f32> and texture_1d<read>. The first is more similar to generics and templates where the templated thing is a type name. Whereas a value is not like generics and more similar to c++ templates. So possible some expansion restrictions.
  • JG: Another alternative is as more arguments to the functions
  • MM: And the args are literals?
    JG: Something like that. Strong and weird restrictions on teh sampler passed. It’s a variable but you can’t reassign it. Effectively a literal constexpr.
  • MM: That’s different. Conceptually you could have a global type Sampler but no local Sampler. DIffeernt concept
  • JG: Different but related. In validation you have to provide as something front he global scope. Could phrase as requiring global flags and you can’t make local variables from them.
  • DN: Already have numbers as the 2nd’ param to the array declaration which I don’t think has been any burden to understanding the language. So, the future concern isn’t concrete at the moment and not much of an impediment.
  • MM: Should say, I think using the <> would be better then more weird restrictions on what functions can take what arguments.
  • DM: Already have restrictions based on the <>s. If you’re sampling from a texture then the dimension of the texture coords depends on if it’s 1d or 2d. The return type depends on the <>.s A float texture you return a float. The grammar depends on that already. In addition, mentioned the access flags dont’ work as generics, but the arguments on storage is exact formats. It isnt’ a wgsl type, it’s a value technically.
  • MM: That’s fair.
  • DS: Sounds like the general idea is to switch to the <> version. Would we keep texture1d?
  • MM: In metal there is no 1d depth.
  • DS: There will likely be restrictions on these already. e.g. template cube
  • DN: Differences with multisample, for eg.
  • DS: [missed]
  • MM: Why aren't these overloads? The stdlib will be a combination of these. It doesn't need to be a validation rule. This is how I’d handle DM’s return type too.
  • DN: I agree. I think we’re discussing whether it is the type that distinguishes this. Whether it goes into the <> or in the name is just appearance to me.
  • DN: If we could embed in the type that would be preferable
  • MM: Agree
  • JG: I think we’d benefit from writing down more examples.
  • JG: Also decide if we want to take this now.
  • DJ: You mean taking the PR as is or finalizing before accepting the PR
  • JG: We should discuss what we want this to look like but if there is a bunch of stuff in the PR that’s useful that isn’t just about what it looks like we might take the whole PR and change how it looks shortly afterwards
  • MM: Right, now there is a texture_sample method which takes a texture_sample but that doesn’t exist now.
  • DS: Assume the underscores are there.
  • MM: I think we just have a big list of the functions that show the types.
  • JG: I do think using the typename would be better, but again we should write them down. I think we’re struggling to discuss this in voice. Let’s come back to it next week.
  • JG: We have competing ideas of how we shoudl present these adn we shoudl write them down. Maybe doing in the PR isn’t the right place, better as an issue? Don’t want to hold the PR as it has value even if we want to change what it looks like.
  • MM: It’s a good starting point, could merge and work on it in the future. YOu said there were no write functions so we’ll need to make changes
  • DS: There are a lot of missing functions at the moment. GLSL has a bazillion functions and I didnt want to list them all right away.
  • MM: I can help make the list.
  • DJ: What about the question of sampled in the name
  • MM: If it has to be htat way it has to be that way.
  • JG: Unless we come up with a better appearance
  • DJ: Should we accept what we have now and open a new issue with the list of names or should we upate the PR
  • DN: Would like to accept PR and open issues for naming form and the set of builtins
  • DJ: That’s what I would say as well. Anyone against
  • DM: Lets merge.

Standard Library

  • MM: This might be a point where we split the stdlib into a different document. If we list all the overloads there will be 50+. Seems like a reasonable idea to split now just for readability.
  • JG: In many specs there is a whole section dedicated to the library. It could just be a section.
  • DN: Don’t know what the perceptual thing is with having multiple documents. Won't print this out so don’t know why that comes into play.
  • MM: If we do the thing where the STL is a section, that would be fine. Sprinkling in the middle is a problem, but self contained as a list at the bottom is fine.
  • DN: Mentioned I’m struggling with grammar, then execution which isn’t described and type rules. Not happy with it but haven’t done anything yet. Having it organized better is a step up.
  • JG: Would help me reading. First thing I do is open and go to the table of contents and find builtins or matrix constructors. So organization goes a long way. Having things related to each other should be organized.

Add text around entry point function. (#906)

  • DS: The real issue here is that we don’t restrict what the entry point can return or accept. This is a pain in Metal.
  • DS: Two options:
    • entry points take no parameters
    • Entry points talke all parameters and have all returns.
  • MM: I like DM’s version but I don’t think we can pass samplers around. That would mean option 1.
  • DN: Thumbs up
  • DM: Talked about on last call and seems to be impossible. Should proceed with the other choice.

Describe module constants, including pipeline-overrideable (#886)

  • DN: Received feedback on flipping around so you can have those constants not have an initializer which requires theAPI to fill in. Added that text to make that allowable. A comment an hour ago on constants which aren’t in the API and not defaulted. I intended to write it’s an error to catch at pipeline creation time.
  • MM: Don’t think spec said that, if it does that’s great
  • DN: If that’s intent, that’s good and we can discuss wording. Line 715 [...]
  • MM: Sounds great, thumbs up.
  • DJ: So accepted as is.
  • MM: One other thought, why are these identified by number and not name. Names have to be unique as they’re all globals.
  • DN: Don’t want to do string processing at runtime?
    MM: Just equality and have to do it for entry point identification.
  • DM: Seems like a fine idea.
  • DN: What character set.
  • MM: We should define that anyway. We have a grammar for identifiers so same as that
  • DN: Same namespace as everything else or own namespace
  • MM: Same as it is for everything else. Input variable and function with same name is module constant and function with same name.
  • DN: RIght now only one name space
  • MM: Sounds great.
  • KN: So, what is the alternative to numbers. You say it’s a module constant and the name is the name of the variable or you get to override the name of the variable like with entry points. Do you identify by it’s identifier or by some string.
  • MM: Don’t have an opinion, if you could have exposed it as different from variable name it should be optional.
  • DN: Want time to think about a concrete proposal
  • JG: Could we accept and modify to change to strings
  • MM: As long as it’s tracked like other issues.
  • DN: Would like a new issue for that.
  • MM: I’ll file the issue.
  • DM: So the rules that say if you use the same location in different shader modules in the shader pipeline would be in webgpu spec? Like the same location has the same type and value.
  • DN: Constant id or pipeline locations
  • DM: Constant id
  • DN: Constant id is scoped to the pipeline you’re creating. So could have the same constant id in frag and vert shaders which map to the same type and same value.
  • KN: So making this change is no ids for constants until pipeline creation time
  • MM: Isn’t that how it works already? Pipeline creation would be where you supply these
  • KN: Not the values, the ids. Impl doesn’t know what id goes with what identifier
  • MM: You could hash the name.
  • KN: Only if hash is resistant to collisions and it’s ok to have large numbers
  • DM: Great point, safer to have ids so we can translate spirv modules
  • KN: If we can’t create spir-v modules from the WGSL source then we’ve failed.
  • MM: If i could come up with a hash function would that solve the problem?
  • DN: Packing impossibility problem. No universal compression scheme that works and is correct.
  • MM: That’s correct. I guess the length of the variable name would have to be shorter then some limit.
  • DN: Variables x1, x3, x4 ….
  • JG: We can think about it. Take this and we can talk about it.
  • DM: Not worth the effort to come up with a hash functions. Thanks Kai for bringing this up. We’re very ahead of the code, we’re designing things where we don’t have code feedback and need to be ready to reconsider.
  • DJ: Accept PR as is and open issue for alternative module constant strings.

Add stride array decoration. (#910) (Addresses Explicit layout needs more than Offset: ArrayStride and matrix attributes (#773))

  • DS: This has come up before with no answer. I really need array strides for compute examples. Here is something we can use for the moment.
  • DS: Adding stride before typed defined arrays. Provides the stride value to be used for arrays inside structures.
  • MM: Downside is you have to create a typedef for every array you pass in from the API
  • DN: Upside is the stride part of the type the typechecker can check things that would be validation errors.
  • MM: Another proposal, make the stride part of the type but don’t require the typedef.
  • DS: So something like array<i32, 5, stride=14>
  • DN: vs stride 16array<i32, 5>
  • MM: This would be one way of doing it.
  • MM: i32[5, 16] or i32[5]|16 or i32[5]16 or or or or….
  • DM: In the current pr the type alias has to have the stride
  • DS: You can have any array type in a type_decl. You get the stride by going down the third branch of that.
  • DJ: Should we accept in order to unblock examples while we have folks add suggestions
  • MM: Depends on if the final solution is additive or not. I don’t think so. The PR is small enough that that syntax question is important.
  • DJ: In which case, suggest we put the alternatives in the PR.
  • MM: Not particular on any possible one. Feedback is making typedefs for all arrays sucks.
  • DM: Host shareable arrays. Not that many.
  • MM: Yes.
  • DM: You have a typedef for ever struct
  • DS: Structures don’t have names in the spec at the moment, but it was decided that they will have at a previous meeting.
  • MM: Structures have names, arrays don’t have names, that’s the difference.
  • DJ: Let's come back to this next week. Put examples into the PR if you want them discussed
  • DN: Another thing to consider, array stride was the first thing, but Matrix RowStride RowMajor ColMajor needed as well. Might affect the syntax.
  • MM: Should we talk about matrices? Or defer to next week?
  • DN: Defer to next week but want people to think about it.
  • MM: I think it’s reasonable to have a different solution for arrays and matrixes.
  • DN: Sure.
  • DM: Is there an issue about matrixes?
  • DS: Same issue.
  • DN: Lets for a new issue, not good to mix them as the details are different. Will write down what vulkan does.
  • DJ: Lets start next meeting with this one and the matrix issue.

bool equality (#913)

  • DS: Does anyone disagree with the text?
  • MM: !=. Yes.
  • DN: Only change was to add the component wise aspect which I can do straight forwardly.
  • DJ: So lets accept that one
Clone this wiki locally