Chair: Corentin
Scribe: Brandon
Location: Google Meet

• Administrivia
• CTS Update
• Clarify resource state validation on submit() #5384
• Reintroduce source maps #4844
• [Immediate Data] Shall we support per-stage immediate data? #5116
• Start discussions on bindless based on the partial proposal:
  • [bindless] Alternative to the GPUBindGroup addition of a variable size "dynamic binding array" #5372
  • [bindless] Stateless alternative to usage pinning? #5378
  • [bindless] What limit for maxDynamicBindingArraySize? #5373
• Milestone 2 API issues triage
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Stephen White
• Mozilla
  • Jim Blandy
  • Teodor Tanasoaia
• Nvidia
  • Anders Leino
  • Fabio Bernardon
  • Markus Tavenrath
• Albin Bernhardsson
• Connor Fitzgerald
• Lee Mighdoll
• Stefan Brendanmair

• None

• Texture Swizzle landed!

• CW: Recaps issue. Found two related issues (#657 and #769) that talk about similar issues. They say “everybody agrees” but cannot find reference for said agreement. Prev resolution was that if resource ends up not being used by a particular stage (IE: A fragment resource when dispatching comupte) then we would still validate that it was alive. Would suggest we keep the behavior as-is.
• KN: Discussion is about usage tracking, which is checking for read/write races. Not quite the same thing. We discussed in depth and were very intentional about our approach. Don’t know that the rules for <something> need to be as strict? Teo’s point that it prevents immediate backend encoding is a strong point.
• JB: Which point?
• KN: Ignoring things that don’t get used.
• TT: The reason I backtracked is that you can avoid problem by adding more tracking. Metal will probably still complain. Could be that if you try to override a specific slot Metal will be fine with it. My example in the description is different from the CTS test. Test is that if you call set bind group with a deleted resource with no draw/dispatch it will still fail validation. Expected that it would only check if resources were used in pass.
• KN: We should check for both.
• CW: It’s always fine to bind an argument buffer in Metal, but you should not submit it.
• TT: Don’t think we use argument buffers?
• CF: Only for bindless arrays.
• KR: Doesn’t Safari always use argument buffers?
• MW: Yes.
• KN: <Vulkan descriptor set concern?>
• CW: As long as you don’t use it it’s fine to bind a descriptor set with destroyed resources.
• JB: Sounds like we are kind of agreed that the strict stance that the CTS enforces is what we want. Only ambiguity is that it’s not clear what “used by any command” means. If we say that includes setBindGroup then clearly the spec would be requiring the behavior that the CTS enforces.
• KN: This text existed before some of that behavior was sorted out.
• KN: Elements in command list are closures.
• CW: Spec should be clearer about that. Closures could mutate the current state?
• JB: No, I understand it. If you look at the way SetBindGroup is specified it doesn’t set the CommandList. Changes state on the encoder. That’s why it’s unclear.
• TT: That’s what I was trying to communicate in issue.
• CW: Can we resolve this? Fix it to match the CTS?
• KN & JB: Yes.
• CW: Without argument buffers it’s a bit annoying, but we can implement?
• JB: Yes.

• Now an API issue: suggested in WGSL meeting that GPUUncapturedErrorEvent and GPUCompilationInfo could include the GPUShaderModule being complained about when appropriate.
• JB: We agreed on the behavior we want to see. For example, WSL users seeing original source. Agreed that we want to adapt comment syntax. Currently ECMA source map standard has per-language clauses. Ideally we can coordinate with them. In practice we can have an informal note referring to another syntax (“Just like Javascript”). Can’t get my head around how Dev Tools are supposed to make it work. Kai point out implementations have back channels. Gregg’s example is entirely about textual re-writes. Based on URLs that identify source maps and allow it to be fetched. WGSL doesn’t have a URL. Browser are free to make up a syntax, but that would be unfriendly to third-party tools, because every browser would do it differently. Maybe I’m missing something. Final point was that it seemed useful to provide module in compilation. Gregg points out that you typically call getCompilationInfo, which requires shader module. Would be nice if we had generic tools that didn’t care where data came from (ie: Third party tools).
• KN: In regards to last point, don’t think that app code will need to look at validation error strings in order to look up the info they want for an error message. Can easily pass both shader module and compilation info easily. Don’t need to put module in compilation info. The errors should just be strings, not anything clever. Purely an implementation detail if URL is used. Just needs to have that information somewhere, not necessarily in the string. If we wanted to apply source maps when printing to console then those error messages should be generated by dev tools, and it should fetch the info from the module. No reason those error messages have to be the string that passed to the API.
• JB: Example that Gregg showed was that he captured message and dumped to console. Console turns error object into string.
• KN: Also GPUError. <Missed some here.> If you take the string off the compilation error and print it you just get that string.
• JB: Sounds like you’re saying these objects can have internal pointers and console stringification can provide a richer output.
• KN: Yes.
• JB: That sounds fine. Was led astray by idea that we were going to have to mimic Chrome behavior.
• LM: The idea is that we’re doing differently than how Typescript/SASS does it? Spidermonkey/V8 register that file has been presented to the browser with dev tools.
• CW: Different because we don’t load actual files, string is passed directly.
• LM: So we would imitate by sending resources loaded list to dev tools.
• CW: That’s one potential way to do it. If someone is trying to make a WebGPU inspector and wants to do validation. Injection makes it easy to get shader modules and annotate.
• LM: That’s an interesting but separate experience. Core experience is what I get in the console. If you follow the Typescript path implementations would need to register that resource is available and give dev tools a way to access with a name/sourcemap. At the point a console message is logged you use the name provided for the WGSL file. Is that how it’s supposed to work? Wasn’t sue if Kai was suggesting that console could produce messages based on original source.
• KN: Was saying user doesn’t pass anything except comment in the source. We should be able to work it out.
• LM: I think that’s right, but that requires that browser implementations take on a lot of work that Dev tools could do otherwise.
• JB: Dev tools and browser implementations are tightly coupled. We could at the very least parse the source map URL, conditionally retain the source code unless no error generated. At the point that one of the objects gets logged Dev tools uses internal APIs to get source map URL and original source, produce something useful.
• LM: Got it, then you don’t need to do the @ syntax.
• JB: Don’t know that that means.
• LM: <Something about logging magic message>
• CW: Sounds like we have consensus. Can we move on to next item?
• JB: Kai has persuaded me it’s feasible.

• CW: Would like to finish last immediate data issue that’s unresolved. Discussion last time said we needed more homework to understand most efficient approach. If you look at Vulkan/D3D12 immediates are unified between stages. Metal it’s per-stage. Given limitations on immediate size and user convenience I’d suggest we don’t have per-stage immediates.
• JB: Mozilla thought not splitting them was fine.
• CW: If no concerns then we’ll just do that!

• Started at Issue #4446.
• Finished Triage!

• CW: Would like to get agreement from group to land the bindless proposal and keep adding to it with issues.
• JB: Yes, proposal is good as a proposal.
• CW: Thank you

• MW: Do we need to add this limit or can we use existing one. My read is it’s not dependent on number of elements in an array but <??> at execution time?
• CF: I just split these off (in wgpu). Problem is Intel Windows Vulkan requires that use use higher limits and you need to be using argument buffers on Metal to get the higher limits. In wgpu we were using standard bindings for everything else. So those would have old limit but things bound bindlessly would be a separate thing. At least if you want to support Intel Win Vulkan and Mac without argument buffers for everything you need to split the limit.
• MW: On Mac should be implementation issue.
• CF: Don’t know if Mozilla has plans to use argument buffers everywhere. It’s a hard transfer for us.
• MW: Understood. Would be worth not adding a dependent limit. If we were to raise the other limits then would have to balance with maximum array size. Becomes burden on end user.
• CW: This was not super clear, but the limits should not be dependent with each other.
• CF: The limit we have is orthogonal. Things in the dynamic array don’t count towards the other limits, and visa versa.
• MW: On Metal the dynamic array limit counts towards the maximum number of textures or buffers that can be used.
• CF: You could also reduce it by 100k and no one would notice, because 500k is an arbitrary number.
• CW: That’s all the time we have.

• Allow binding zero-sized GPUBufferBindings #5312