Skip to content

WGSL 2020 10 13

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

:

 Chair
Dan Sinclair and everyone

:

 ⌨️ 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
    • Corentin Wallez
    • Dan Sinclair
    • David Neto
    • Kai Ninomiya
    • Ryan Harrison
    • Sarah Mashayekhi
  • Intel
    • Yunchao He
    • Narifumi Iwamoto
  • Microsoft
    • Damyan Pepper
    • Greg Roth
    • Michael Dougherty
    • Rafael Cintron
    • Tex Riddell
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Kings Distributed Systems
    • Daniel Desjardins
    • Dominic Cerisano
    • Hamada Gasmallah
    • Wes Garland
  • Joshua Groves
  • Kris & Paul Leathers
  • Lukasz Pasek
  • Matijs Toonen
  • Mehmet Oguz Derin
  • Pelle Johnsen
  • Timo de Kort
  • Tyler Larson

⚖️ Discussion

Administrative stuff

  • CW: VF2F administrivia, that will also be sent via email:
    • Please add all topics you'd like to discuss to the VF2F Day 1 agenda, including some of the more complicated PRs.
    • The expectation is that we'll start the VF2F with small status updates maybe demos. Then we'll split between WGSL and the API with more a focus on WGSL.
    • Not everyone will be present all the time, if there's a topic that you really want to be present for, please add time constraints next to it on the agenda (like "not Mon 10-11AM" or "not Tue"). Later this week we'll try to do a global optimization on the schedule.
    • The first hour of Thursday conflicts with the WebGL regular meeting, do we cancel that first hour, or talk about topics that folks in the WebGL group are less interested in? (some WGSL details maybe?)
  • JG: Some other groups post notes back to issues instead of just a link to the discussion doc
  • DJ: CSS group does this, makes a click to show thing. Looked to see if we could do this, will take an AI.
  • CW: Would be handy
  • DS: Would be handy versus digging through the doc to find what you care about
  • MM: If we can’t do automatic, should we do manual?
  • DJ: Will probably start with manual.
  • CW: Should be doable at least from Google Docs side. Need github api tokens and things to post stuff.

Pull requests

  • [wgsl] Elaborate storage classes section
    https://github.com/gpuweb/gpuweb/pull/1093
    • DS: [describes the big changes - renames and removal of some things]
    • DS: There is a HandleStorageClass that doesn’t really exist, but will be the one for images and uniform constant things.
    • DM: What are UniformBuffers renamed to?
    • DS: We have “Uniform”
    • DM: And “Buffer”? So “Uniform” only is for UniformBuffers? Seems inconsistent. Prefer “UniformBuffer” or Uniform/Storage.
    • DS: Uniform/Storage works.
    • DJ: Agreement for uniform/storage. Anyone can update for PR or we’ll wait for DN to get back and update as needed.
  • Allow e.g. if (cond) break/continue/return/kill; without brackets.
    https://github.com/gpuweb/gpuweb/pull/705
    • JG: Waiting on me
  • wgsl: describe builtin variables and how to declare them
    https://github.com/gpuweb/gpuweb/pull/1142
    • DS: Depends on #1093, so a bit confusing. When reviewing, keep that in mind.

Allow identity conversion of vectors. (#1103)

  • MM : We should have it.
  • DS: To clarify, if i say float32(1.f) it should just work.
  • RM: Generally agree it should work. Question of the issue talks about OpCopyObject, why doens’t it….
  • DS: Because if one is a struct you want to copy it, rather than use the same one twice.
  • MM: Ids are immutable.
  • DS: So waht does OpCopyObject do?
  • RM: Don’t know why you’d want to copy structs.
  • DS: David might need to answer this.
  • RM: Let’s delay this for David?
  • DS: Or merge and open this OpCopyObject as an issue?
  • JG: This isn’t a PR yet.
  • JG: Unclear on what this is adding.
  • DS: No typecast from the same type to itself.
  • MM: Useful for joining snippets of code or DIY templating
  • DS: Outstanding q is whether this needs to be OpCopyObject or if we can use the id again.
  • MM: Should not affect behaviour

Query size of texture (#1107)

  • DS: This is so i could get to robust buffer access. This is the list of functions that DM and I came up with.
  • DS: Ben has been comparing the methods between Metal, D3D and Vulkan.
  • MM: In the issue, the top section is for the size of the biggest mip.
  • DS: I thought those were the non-mip one.
  • JG: I think it is for the base level, as MM said. You can then calculate the others.
  • MM: I see a few that could have mip-chains.
  • MM: I think we should simply take the intersection of all APIs.
  • DS: That’s what Ben is doing.
  • DS: We don’t need to rush here.
  • DM: What was the concern?
  • MM: textureRO, textureSampled, etc - all three can have mip-maps. I think this is a good start and all will be in WGSL. Just might be more to consider.
  • JG: Should we always return a vec3 for size rather than different return types?
  • JG: Most APIs give you a vec3. e.g. a 2d texture would provide (x, y, 1) to show a depth of 1. Means you don’t get a different type based on the parameter. Makes code changes easier.
  • MM: That makes sense, but the counter argument would be that the code change would become a behaviour error rather than a compile error.
  • DS: Current return values match SPIR-V
  • JG: This comes from my experience with graphics APIs in general.
  • MM: Since we have different types in parameters, i think it makes sense to keep the return types aligned with the parameter type.
  • DJ: Dan will turn this into a PR. Waiting for Ben to finish his investigation, but this bit is ok to go.

Introduce operator precedence table (#1111)

  • DS: The big question is regarding changing the precedence of things.
  • MM: Another question that is also important is that some say require parentheses. Would like a more rigorous description of require parens
  • MD: Agree it should be clarified. Should do #1136 first. For require parens that’s how rust defines it which isn’t very detailed. Can take another look at it or change the wording
  • MM: Can you describe what it means? What do you intend?
  • MD: These should not be grouped by themselves, but should require additional parens in case they come side by side as there is no precedence between them. Need additional helpers in the syntax
  • JG: a == b == false
  • MM: Right, requires parens. If (a == b && c) is ambiguous so requires parens?
  • KN: Strongly in favour of requiring parens for these cases to avoid weirdness
  • MM: Just curious what that means, how do we make that rigorous?
  • KN: Would be represented by the grammar. Would be hard in a table
  • JG: Would be hard in the grammar. Need parens around it, but don’t want if ((a == b))
  • RM: Could make it work in the grammar by essentially skipping a level of precedence. Saying that x == y is valid but that the sides of it must be at the highest level of precedence. Very simple expressions.
  • KN: Was thinking a different production for each type. 2 productions for expressions.
  • MM: Having trouble following. Could you write a snippet of a few different operators and what the repercussions would be? If you wanted to mix an op that requires and one that doesn’t, or two that require parens. What the productions would look like.
  • RM: I can give it a try. Not sure if it would match what rust does.
  • MM: If we go this direction, what makes the most sense for precedence is keep the same stack as c and GLSL and MSL have. SPIR-V doesn’t have the concept. Essentially match all shading languages which have them, but sya some of the valid expressions in those languages are invalid in WGSL because not enough parens. The precedence stack is the same stack.
  • MD: Close to original version of the PR. The associativity column reads a bit weird for require parens.
  • RM: Seeing non-associativity still applies it’s order with things like %. So, ordering a == b < c which I think we want to forbid without parens.
  • KN: Would be more rules then can be written here. Doesn’t have to be part of this PR.
  • MD: So, close 1136, reorder expression sections.
  • DS: Yes. We don’t want to change precedence.
  • MM: Would be a mistake for precedence order to be different from all other shading languages.
  • KN: Does it change it or clarify?
  • DS: Changes to match rust, original was based on GLSL.
  • DM: If parens are required, why does table order matter?
  • MM: Right, why I’d like examples. I don’t know the answer of that question.
  • KN: Table will be come partially ordered.
  • RM: Yes. I think that’s fine just add some *’s and paragraphs explaining. Just want us to have an open issue so we don’t forget to add the paragraph.
  • MM: If this turns out to be hard, just matching C is probably fine. Agree removing ambiguity is good, but don’t want to make it super difficult.
  • JG: Does help we’re being super restrictive on type matching. That matching restriction means (a ==b) turns into a bool, so you would’nt say (a == b < 3) as bool < 3 doesn’t make sense.
  • MD: So, will revert PR to match C and GLSL.
  • MM: Yea, start from there and we can build a partial ordering of these ops and can work in where parens are required in the grammar. Seems like a big task but if we can do it would be great
  • MD: associativity is marked as left-to-right as per GLSL and C not sure if that’s OK
  • JG: That’s fine, matches what exists currently.
  • DJ: So, 1136 is closed without merging. 1111 is updated to match C and GLSL precedence. Plus more words and notes around extra bits.

Restrictions on function parameters (#1139)

  • DJ: 2 parts to this issue, 1- restriction on function params 2- if we can pass textures as function params.
  • MM: First one is interesting, second isn’t and probably easy to resolve. I think we should not be allowed to do it because you can’t do it in SPIR-V.
  • JG: I think it’s a little more complicated than that.
  • KN: You could implement by unrolling
  • MM: Would have to specialize functions in SPIR-V. Folks have displayed a resistance to that. DN said he’d prefer to not specialize which I think is reasonable due to exponential explosion. 2 models. 1- main accepts the resources as arguments and you pass those around to functions which metal does. 2- resources are all global and you don’t pass them around which is the WGSL model.
  • KN: I think it’s possible to restrict how you pass these objects around to prevent specialization from occurring, you require that each function only gets one particular value.
  • MM: Seems kinda author hostile. Called it here and it worked, next line calls and it doesn’t.
  • JG: Doesn’t work at compile time, and gives more flexibility than before. Like an intermediate piece of shading writing knowledge
  • MM: Breaks down when 2 people are writing shader.
  • KN: If function signature describes which can be passed in would be OK.
  • JG: Confused where constraint comes from. The restriction we have, ala GLSL is you have to be able to unroll the code you generate. It has to be unrollable. It has to function as though it was inlined and when you inlined it you could see which immutable texture handle you were passing in or which of an array of texture handles you passed in. Sounds like the case in SPIR-V without variable storage buffers. I think Metal is at least that flexible.
  • MM: Metal is flexible, not the limiting factor here
  • JG: Just need to know how to say it or say it’s too complicated. Need function to take texture and call from 2 places. Main { foo(texture_a); if (b) { foo(texture_b);}} can always tell which you’re calling it. Could also use textures multiple times but have to know the exhaustive set of textures used by builtin functions
  • MM: Right, I think that require specializing the function
  • JG: If you write the function yourself, yes.
  • MM: I mean a WGSL -> SPIR-V compiler would have to specialize.
  • JG: I don’t think so. This is the part where DNs last comment comes in. You can have ptr operand to a function call must be either … blah blah … … That’s just what we have to do for WGSL to SPIR-V in general. The problem is it’s tricky to specify, not that it’s complicated to do.
  • MM: Don’t understand SPIR-V super well. If you have a function taking a pointer to a texture and the operation to sample the texture doesn't take a pointer. Somewhere between the func signature and the sample you have to load from the pointer. Is that true and if so is that valid?
  • JG: Probably and probably? I can’t give an authoritative SPIR-V answer. That style is how GLSL works.
  • MM: In glsl you can have functions with texture arguments?
  • JG: Yes.
  • MM: Mind blown.
  • JG: Kind of like they’re specialized.
  • MM: So does GLSL have arrays of textures?
  • JG: Yes
  • MM: So you couldn’t call that function with a dynamically computed index into a texture array as you don’t know how to specialize?
  • JG: Yes you can do that. Arrays of textures have tricky rules in GLSL so you can do things like that.
  • MM: Maybe we should wait for DN.
  • JG: Would be good to get authoritative SPIR-V answers. Let’s postpone that.
  • MM: For the types of storage classes passed into functions, we need to figure out how to expose that to the programmer as it would be surprising to pass a var and it works and pass a buffer and it fails
  • JG: I think this is talking about UBOs
  • MM: Given a UBO you can take a pointer to an element inside it.
  • JG: I don't think you can do that in WGSL?
  • DS: I believe you can with the ptr type var i : ptr&lt;function, f32> = foo.a;
  • JG: I think users might just end up being surprised.
  • MM: If foo is in an ssbo, the ‘function’ is something else?
  • DS: I believe buffer in that case
  • MM: Right, then you can pass a pointer where the thing is in the list and then that restricts it.
  • DS: When you pass a pointer into a function it has a type and a storage class.

Define the interface of an entry point in a WGSL program (#774)

shader programming model: permitted memory orders on control barriers (#232)

Issue with type converting module scoped variables (#1104)

Is Input/Output access one-way? (#1113)

Invariant qualifier (#893)

Method of ensuring GPUShaderModules can contain MTLLibraries (#1064)

what is the initial value of a workgroup variable? (#1137)

Reorder expression sections (#1136)

  • DS: Resolve to close and keep the current precedence.
Clone this wiki locally