Chair: Corentin

Scribe: Ken/Austin

Location: Google Meet

• Which meeting to cancel for the holidays?
• CTS updates
• Milestone triage (timebox 15m) #2073 (currently triaging V1 issues, start at #1842)
• GPUAdapter.name considered harmful #2191 (timebox 20m)
  • And discuss Brandon's proposal in Exposing GPU hardware information to web developers in WebGPU #2195
• texture_2d_depth for loading depth values might be unnecessary? #2094
• (stretch) Expose blocking operations on workers #2217
• (stretch) Cannot upload/download to UMA storage buffer without an unnecessary copy and unnecessary memory use #2388
• Agenda for next meeting

This week's 5 issues to try and resolve offline:

• Binding to zero-sized range of a buffer #686
• Copies of depth values outside [0, 1] #789
• Separate loadOp and clear values #2386
• Should it be possible to create 3D depth textures? #2304
• Make depth/stencil load and store ops optional for read only #2387

• Apple
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Loko Kung
• Microsoft
  • Rafael Cintron
• Mozilla
  • Dzmitry Malyshau
• Brendan Duncan

• Next meeting Jan 12
• APAC timed meeting?
  • KN: sounds fine
• MM: Office hours meeting next week?
  • CW: don't know. Not very official. If ppl show up there will be one.

• CW: Updates to floating point builtins tests to correctly round results.
• CW: Contributions from Intel checking out-of-bounds rendering, drawIndexedIndirect when index buffer is out-of-bounds
• CW: Please contribute! Especially if your implementation tests against it.
• MM: we're implementing this. Since we want to compile early (at createShaderModule()), we can’t use vertex pulling, so all these draw calls will become indirect for us.

• Should the API enforce that writable storage buffer bindings don't alias each other? #1842
  • CW: Do we need to define how things alias?
  • MM: thought we agreed - spec'd say it's not allowed, but some impls wouldn't enforce it?
  • DM: don't remember us defining the same synchronization scope. Same draw call / shader?
  • CW: Editorial. Just need to write the spec.
  • MM: I made a PR for this and someone didn't like it. Think that's where it was left.
  • CW: let's re-review the PR.
  • CW: resolved: for offline resolution.
• #1847
• #1884
  • KN: If we do it, should to it for v1
  • CW: let's resolve offline then.
• #1962 shader stage variables
  • KN: thought we resolved this one
  • CW: need for V1. This is for user-defined I/O. Need to decide that.
  • CW: Great thing to discuss offline. Guess the answer will be yes.
  • MM: can a vertex shader output be location 5000?
  • CW: correct. Think answer will be no.
• #1977 problems with default queue
  • CW: also something MM raised in UMA discussion.
  • CW: buffer given back to GPU. In future with multi-queue we don't know what to do with it.
  • CW: think we can close this. I'll remember the gpuUnmapOption idea. It's written down in the issue here.
  • DM: that's fine.
  • MM: when we add more queues we can make sure that every place that takes the default queue today take another dictionary member.
• #1999
  • CW: something we're ready to do?
  • KN: think we can close it unless we run into blocking issues implementing things.
  • CW: DM / LK can you talk with each other offline about Vullkan's guarantees around robust buffer access? Similar to this problem, but worse on Vulkan.
  • LK: I see Kai's comment about robust buffer access - same issue that we ran across internally.
• #2043 holes in pipeline layout
  • CW: do we want to do anything for this in V1? Shader which uses groups 0 and 2, have to bind empty BGL to group 1.
  • MM: think we should just fix this now
  • DM: think we shouldn't make changes here - it's not supported natively by Vulkan for example.
  • DM: this is too niche a use case.
  • MM: so you're saying WebGPU should never support this? Or defer till post-V1?
  • DM: if we get ISV feedback about this then we should do it
  • KR: didn't Brendan Duncan from Unity run into this?
  • BD: yes, but were able to work around it in our shader compiler, so doesn't bother me either way
• #2060
  • KN: want to be able to do a partial discard
  • MM: scenario: had precompiled shader, want to reuse it and intentionally disable renderbuffers
  • KG: figuring out whether to decide in V1, or decide it overall?
  • CW: worth discussing for V1, or later.
  • KG: we should discuss in V1.
• #2072
  • KG: getMappedRange and then transfer it to a worker, what happens?
  • KN: need to figure this out.
  • CW: OK, figure out for V1.
• CW: done with triage. Next time start at #2073 (?)

• And discuss Brandon's proposal in Exposing GPU hardware information to web developers in WebGPU #2195
• MM: we propose to not discuss this for V1. Appears nobody's using this string today in WebGPU.
• KG: think this is an important part for shipping.
• BJ: agree. Kai discussed why people aren't using this today in the last call. Wouldn't expect people to be shipping on it broadly now.
• KG: The reason this is important for me for V1 is say a large popular maps application switches to WebGPU, and a large driver vendor ships a bug - I want there to be a way to quickly ship workarounds.
• BJ: absolute worst thing for us as a group would be for us to have some large app developer to bet on WebGPU (it'll be early, there'll be rough transition period) and walk away saying - we could have fixed this if we'd stuck with WebGL, but because we used WebGPU we didn't have access to things to let us work around the problem.
• KG: or they make WebGL context and grab the info from it anyway.
• BJ: Yes, that'll definitely happen.
• KG: for user story of this API, making it good, happy releasing it - harsh realities out there given my experience with WebGL - this is an important aspect for shipping, even if some people don't use it that way.
• MM: particularly interested in hearing from people who haven't weighed in on the discussion yet.
• RC: for this issue - think we should definitely have something. Don't think it should be as freeform as what we have in WebGL, a string containing all manner of stuff that you have to parse. Think it should be structured. Vendor, generation, etc. Esp. with compute shaders, knowing what to pass in # workagroups, algorithm to use - you need to know the GPU generation. Thikn we should give devs something, not unstructured, and maybe not as much info as WebGL. Have seen the temptation - people go and ask WebGL, and then they guess they're running on the same adapter as WebGPU. May be true today, but an avenue for things breaking in the future.
• KG: I have impl concerns about makign things too structured, and difficulty there. We don't have this strong structuring in Firefox. Making it strongly structured, we'd do our best - but sort of don't want to bother. First approximation - categorize into vendors - can be found by looking at rendering artifacts. Going further is nice - but wary of signing up to do better job than we do today in the browser.
• RC: to give you a sense of how unstructured it is in WebGL - here's mine:
  • ANGLE (NVIDIA, NVIDIA GeForce GTX 965M Direct3D11 vs_5_0 ps_5_0, D3D11-26.21.14.4587)
• Very unstructured. Hyphen here, driver version there, etc. SHould be more structured than this, but agree there's only so muhc we can do to structure it.
• KG: more info you want to pull out, the harder you have to work, and I'm OK with that. Which device is it? Or, you have bug reports from a specific device we'll collate those. But maybe we have buckets. Could provide something useful without having to do a lot of work to structure things. Acutely aware of how painful version strings are - working with them in Firefox right now. Having a hard time. Happy with WebGL's status quo - we try to do an OK job. What we do is good enough for what people ask for. Could be better, maybe. Wouldn't stand in the way of improvements, just don't want to do it.
• BJ: in context of proposal in #2195 - idea of parsing out device IDs and turn them into reasonable arch / family does seem intimidating. If we could find way to do it, would be the right cutting point between privacy-preserving and helpful to devs. Should be non-controversial: we can report a reasonably good vendor everywhere. Devices are muhc more complicated. Structure of my proposal - it is well structured. Kai suggested internally that maybe this is the only non-nullable thing - you could say "Unknown", easier for devs to work with. Past that, should all be nullable. Individual UA's comfort level providing this, or ability to parse out the info. Not ideal from developer's POV. Not sure what breakup of properties should be, but think we should break them up to some degree, and ability for a UA to put a line in the structure - everything more detailed than this I want user consent for. Everything less, give to the drive-by web. A lot of wiggle room in here. Don't expect we'll come to consensus. but would be nice to come to conclusions about what the useful properties in this structure are, and can we reasonably populate it as Kelsey was concerned about - I'm concerned about it too.
• MM: propose deferring the rest of this discussion for another meeting - the next meeting - unless someone who hasn't spoken yet has thoughts.
• CW: sounds like it will be in about a month.
• KG: that's oK.
• BJ: one more thing please. Fine with me if we want to timebox this and move on - but it seems to me that most discussion on Github is community driven. Developers arguing passionately about the info they need. Ken had to jump in and tone it down. Would be helpful if folks who have concerns about these proposals provide written replies on Github so we don't have to timebox these discussions in 20 min or so.
• KG: understand. The community feedback is valuable but signal-to-noise ratio is a bit low. :) Not much new information we don't already have.
• BJ: not advocating for answering all community complaints - don't think tha'ts beneficial - but if more publicly visible discussion from implementers on these topics, rather than keeping everything to calls - would help perception that we're making progress on it, and would help us actually make progress on it. Keeping some of the WG discussion on Github would be beneficial.
• CW: second that. More generally - want that for more issues. Still a lot of things to decide to finish V1, and not much meeting time - saying, please make progress on this offline.
• CW: at the point where we can say in many situations - I don't care too much about whether it gets into V1, let's just do something - we will do more work post V1.

• CW: we already have texture gather. For depth textures seems it would work? Like Kai's suggestion in the last comment? Can return any yzw in the return value.
• MM: for gathering or sampling?
• KN: for sampling. May affect gather too.
• MM: gather, you know the component at compilation time.
• KN: yes but you don't know whether it's depth/stencil or not.
• MM: you do, you know the binding type.
• KN: right, you do, in the pipeline. But like I mentioned: same for gather/sample; could get the info if we want to do pipeline compilation on all backends.
• MM: thought Metal was the only one that's flexible. Other APIs, thought you get X001.
• CW: can use texture swizzling for that if APIs don't guarantee? Texture view returns R00.
• KN: even on depth textures can use swizzling?
• CW: don't see why not. Can always fall back to what we'd do for Metal.
• MM: can't use swizzling to solve in Metal - if you do use swizzling, can't bind depth texture as renderbuffer, and they're pretty useful as renderbuffers. Proposal here:
  • 1. Language does have a depth texture type
  • 2. A program is not required to attach all depth textures to the language's depth texture type
  • 3. Fully define what a sampling operation does in the mismatch situation
  • 4. Implement that by having compilers which produce Metal know whether a texture in the shading language is backed by a depth texture and emit different code in that situation
• CW: probably pipeline overridable constant, internally. Doable with that.
• MM: when you compile you know pipeline layout. Know for each texture whether it'll be backed by depth texture or not. Emit different code.
• CW: right.
• MM: fully defined behavior - X001 if sampling from depth texture. Gather from depth texture should be error unless gathering the first component.
• KG: pipeline creation error?
• MM: yes. Compiling early is a hint.
• DM; earlier we agreed on stencil. Able to return undefined values in yzw components.
• CW: because we don't know the pipeline layout.
• DM: if we have that, any reason to not just disallow this for depth as well? E.g. do the same thing here?
• MM: agreement on stencil - allow non portable behavior. Because it's rare, we allow it as a wart in the API. Not rare for depth.
• CW: depth is much more common. If it's depth or float32 - we don't know in pipeline layout whether it's depth or u32 (?).
• DM: tha'ts the main problem to solve. Whether we need to know at pipeline layout.
• MM: one possibility - add new binding type for stencil. Probably doesn't make sense because of rarity argument I just made.
• DM: question is how often ppl will take yzw components of depth texture. Not a question of how often they'll use the depth texture.
• KN: agree. Just because it's more common and people are mor elikely to read those components when they shouldn't doesn't make the argument to me. People shouldn't read those components. Say they're technically undefined.
• MM: can't easily define for stencils, but can for depth textures.
• CW: since we're injecting code anyway, yes. Because we can, we should define it. Either way sounds fine.
• MM: no reason to not define it.
• DM: path where we follow the stencil - more consistent with stencil, easier to implement, and more flexible for users - can use same pipeline layout for depth and non-depth if they aren't comparison sampling. Better for everybody.
• CW: so make depth sampling compatible with float32?
• KN: different thing than what we're discussing.
• MM: think if we try to match depth and stencil behavior - add new stencil binding type, not remove depth binding type.
• CW: depth binding type required for comparison sampling.
• KN: had solution - at pipeline creation time, know whether texture's depth or not. If not part of layout any more - allow depth textures to be bound to float points in the BGL - we can't do that anymore.
• DM: that's what I'm saying. Use the info for shader generation - or follow the rules we chose for stencil. Use other components - you get undefined values.
• MM: biggest argument against that is gather. Can't guarantee you'd only gather the first component. Trying to gather Y component of depth texture - might not do something stencil.
• DM: so not undefined value for gather case, things may crash?
• MM: wouldn't phrase it that way. Confident that the behavior works when you're sampling from a depth texture, happening in the wild. Can't say the same for gathering from depth textures.
• DM: what about gathering from stencil textures?
• MM: not ure.
• KN: here, we were trying to resolve the issue that Metal requise a depth texture type in the shader.
• DM: 2 ways to solve that, and neither one requires shader to know the depth_texture type.
• KN: how do we know that if we don't know it in the pipeline layout (?).
• DM: shader sees it as f32 texture.
• MM: you cross your fingers and pray.
• MM: said this was OK before we had gather. If nothing in type system - don't know if you'll call gather..
• DM: we don't know this for stencil today.
• CW: maybe an argument for stencil type binding. But maybe, no gather for you?
• MM: no gather in language?
• CW: no. Depth textures = only sample type in pipeline layout. Compiling shader, see f32 texture, has gather operation on it, and it's a depth type texture - no, you can't gather. Boom.
• MM: binding type for depth texture?
• CW: yes. And if you have depth sample type, that binding, when matching against shader, can't be used for gather operations.
• MM: if we know texture's depth type in BGL - we can issue gather calls, but only if the gather call's against the first component.
• CW: that's a fine thing to validate.
• MM: that's the idea - if shader says f32 texture but API's bind point says depth texture, when you compile together, that f32 texture in WGSL source code doesn't turn into f32 texture in Metal source code.
• CW: apologies, yes.
• KN: ok with that. Just taking issue with Dzmitry's alternate formulation.
• DM: MM confirmed that for non-gather it's OK to do this. Have same problem on stencil. Doing this path doesn't bring us to new places.
• KN: thought previously that this wasn't OK. Waited for Myles, now we have his response.
• MM: my response wasn't about gathering on stencil textures.
• KN: but it's OK in Metal to bind depth texture to non-depth binding point in shader and sample from it.
• MM: yes.
• KN: OK, thought we didn't want to do that.
• MM: if we can avoid it that'd be better than having to exploit this contrary but still somewhat supported behavior. Middle ground - adding new type but not to the shading language - is middle ground.
• KN: I like the solution.
• CW: what about gathering on stencil?
• MM: not sure, will add it to my TODO list.
• DM: if we have different binding type, not the end of the world. Want consistency between depth/stencil, nothing more.
• MM: reason stencil's different is Metal doesn't have stencil type in the shading language. Gathering against stencil texture => shading language wouldn't know it is one.
• KN: would we need to prevent users from doing this?
• MM: I assume no but will verify.

• CW: GPUAdapter.name considered harmful #2191 (timebox 20m)
  • And discuss Brandon's proposal in Exposing GPU hardware information to web developers in WebGPU #2195
• CW: Synchronous operations in workers
  • Interesting to Intel. APAC meeting, they'll be able to join
• Probably enough for a meeting.
• CW: please let's strive to resolve things offline. Number of things for this week; resolved a couple. Will send a new list before the holidays.
• Happy holidays and New Year everyone!
• For offline resolution
  • Describe resource aliasing rules #2065
  • Make error scope objects have same shape as DOMExceptions? #1884
  • Should we constrain the location of user input-output stage variables WGSL #1962