Minutes 2022 07 13

GPU Web 2022-07-13

Chair: Corentin / Kelsey

Scribe: Ken

Location: Google Meet

Tentative agenda

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• Criteria for pushing the WebGPU and WGSL specification to Candidate Recommendation #3107
• Shader stage input-output subsetting rules #2038
  • Allow inter-stage variable subsetting #3122
• Describe "mapped range ArrayBuffers" in terms of copies #3124
• Specify that texture_external sampling functions clamp coords to [0, 1] #2766
• Should objects have pointers back to their parents? #1497
• Agenda for next meeting

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
• Microsoft
  • Jesse Natalie
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Michael Shannon

Administrivia

• Call for editors!
  • Closes in ~3 weeks.

CTS Update

• KN: little work on resource usage scope validation tests
• KN: would like to keep working on one-file-per-test - no chance to work on that recently.
  • Couple small changes. Keep working with Myles/Kelsey on what's needed.
• MM: work you've already done is sufficient - couple of improvements possible here/there, but not substantial. Can consider issue closed.
• KN: I should plumb through the things that let you split up the tests. Will do that before closing.
• MM: thanks so much for taking care of this.

“Tacit Resolution” Queue

• Allow BGL entries for multisampled:true "depth" textures #3072
  • CW: changes validation. Think was just a bug in the spec.
  • KN: if anyone knows why this wouldn't have been true - let us know. Pretty sure just an error in an earlier PR.
  • MM: if some scenario - testing will find it. Should proceed under the assumption it was an error.
• Say that shaders must (dynamically) terminate #3126
  • KG: sounds good.
• Make mapping ArrayBuffers non-detachable #3160
  • KN: not just editorial. Previously decided - if you try to transfer, you get a copy. Magically stop watching changes to it. You get a copy, and the copy stops being attached to the mapped range. This makes it an error to transfer. Jim looked at ECMAScript spec - there's a mechanism for this, thank you. No spec changes needed upstream in ECMAScript spec.
  • MM: reason I'm convinced this is a good idea - transferring can happen 2 ways, transferring and copy. Copy way will still work - just don't put the ArrayBuffer in the transfer list.
  • MM/KN: Shouldn’t copy when user asked for a move.
  • KG: I'd like more prose description of what this change is doing.
  • KN: we can do that. Will also put a helpful error message in.

Criteria for pushing the WebGPU and WGSL specification to Candidate Recommendation #3107

• CW: Francois Daoust explained that we should seek review from other interested groups through [email protected] and reaching out to them directly. What groups do we think might be interested (both inside and outside of W3C)?
  • Obvious one: immersive web
  • Media
  • Others?
• RC: Machine Learning group.
• MM: should WebCodecs be involved?
  • KG: seems fine.
  • CW: is that in Media? Not sure.
• KN: not W3C, but HTML / Domenic. Do we want more reviewers? An open issue about integrating better with HTML Canvas spec already, maybe don't need more discussion.
• CW: WebKit made <model> tag proposal, is that standardized anywhere?
  • KG: ended up in Immersive Web charter.
  • MM: Let's not put this on the official list (yet), but I'll ask people who are working on that project.
• CW: WebAssembly. Lots of stuff to do, but we'll ship before they can do anything.
  • KG: would be nice to get thumbs-up from them.
  • MM: concerned they'd tear up the spec, saying we have to redesign everything.
  • KG: my management chain is supportive.
  • JB: not concerned about ArrayBuffer mapping, for example?
  • KG: think reaching out to them is a good idea.
  • CW: we also reached out to Wasm in 2019 - said we needed memory mapping and a nice way to work with in Wasm. No motion.
  • KG: think we'd need to spearhead a proposal.
• CW: already a lot. Hopefully not too many requests for changes. Late for that.

Shader stage input-output subsetting rules #2038

• Allow inter-stage variable subsetting #3122
• KN: PR here defines: fragment inputs must be subset of vertex outputs. Removes existing rule saying the opposite subset relationship has to be true.
• KN: issue: implementing on D3D. Per Jesse on email: D3D itself doesn't have restrictions here. Ordering restrictions are in prefixing. Shader compilers do register allocation separately for VS output / FS input. Have to line up after reg allocation is done. If generating DXBC / DXIL ourselves, wouldn't be a problem. But going through HLSL, have to make them line up. Proposal: insert whatever fragment inputs we need to space things out and make reg allocation work. Put some extra stuff in there. Drivers won't notice it's unused and try to optimize it away. Indices limited to ~30, so can't have more than 30 bits of extra space anyway. At pipeline creation time - can pack things together, eliminate unused vertex outputs.
• KN: think that's enough impl options that I'm comfortable putting this in the spec. Impls can do whatever they want to make this work.
• MM: did you (correctly) assume we're designing WGSL/WebGPU to compile to HLSL rather than DXBC/DXIL. Is that written anywhere? It affects the design.
• CW: where would we write this? In the WGSL spec?
• MM: that's one option. Another: there's a pinned issue, what are we targeting? Talks about Metal device families. Saying in there that we're targeting HLSL is probably a good idea.
• MM: only way to implement this is at pipeline creation time. If can't compare VS / FS - don't know what to insert. Intentional decision?
• KN: can do it at createSHaderModule. Insert dummy inputs for every slot up to the last one that's used. If you use 1 and 6 - we'll insert dummy values for 0, 2, 3, 4, 5. In both VS and FS, so they end up with the same interface.
• MM: will that make rasterization slow?
• KN: wait, that might not work, won't know outputs / types.
• MM: maybe treat everything as vec4?
• KN: don't know if that's valid.
• JN: think that'd be fine.
• CW: there'd be rasterization cost - # vertex attribs being stored would be bigger. It works though. Motivation for compilers to do cross-stage optimization. Cheap-ish?
• KN: think costs only high if people using very sparse varying indices.
• JB: Naga's HLSL output for VS outputs and FS inputs - we put a thing :loc0, :loc1 on all structures. Is that not explicitly assigning the locations we were talking about adding slots fro?
• JN: they're not. Those are semantics, they can be arbitrary. After reg allocation, semantic names have to match between the shaders.
• MM: so doesn't affect codegen.
• JN: pretty much.
• JB: but if we mess up alignment it'll fail to link.
• JN: yes, D3D12 will fail to link the PSO.
• JN: I agree there are 2 options. Do at shader comp time, pay the perf cost - or defer until pipeline creation. Reasonable tradeoff for impl to make.
• KN: also if you're using dxc, we could go in there and control the reg allocation somehow.
• JN: think we have a tracking feature for HLSL to add this. Problem will go away eventually.
• MS: caution against relying against driver optimization. Recently had bug, lack of driver optimization on one platform caused inputs to not line up.
• MM: right now HLSL impls are compiling at pipeline creation. Not relying on driver opts right now. Long term we have RFE against HLSL compiler.
• CW: general agreement, so let's go with that.

Describe "mapped range ArrayBuffers" in terms of copies #3124

• Superseded by Make mapping ArrayBuffers non-detachable #3160 if accepted
• CW: skipping this as it's similar to the tacit resolution discussion.

Specify that texture_external sampling functions clamp coords to [0, 1] #2766

• MM: Can we postpone this for a week? Kai wrote a big thing and I had a semi-insightful reply but my machine crashed and I lost the whole thing. (Seriously.) Think we're at the point where we're in the middle of a complex discussion, better written than spoken.
• CW: Intel found on some systems, using WebGPU rather than WebGL for videoconferencing - went from 20W of system power, to 13-ish. (!) In Chrome, so caveats. But zero-copy does matter.
• MM: that's exciting. WebGL version, is that using texImage2D, or WEBGL_video_texture that's not done?
• CW: texImage2D.

Should objects have pointers back to their parents? #1497

• Is resolved?
• Was closed by #3168, which added a non-normative note encouraging implementations to not retain strong parent references but not requiring it.
• CW: KG you wanted more time to think about this?
• KG: where we left off, I think - seemed to be consensus to allow impls to hold onto these. Not good idea, but won't fight about it. Probably, all will do the thing where it's all weakrefs or you leak memory. Happy to say in spec, it's up to you - just like GC / cycle collection's up to teh UA.
• BJ: non-normative note - don't depend on GC. Hold on to single buffer? Don't expect GC to pick up everything else for you. If you really want things cleaned up, call destroy().
• MM: so resolution here - objects won't have pointers to their parents.
• KG: WebIDL won't expose them, yes.
• BJ: if the impl holds on to parent references, that's impl detail.
• MM: OK.
• KG: can't preserve weakref behavior and also expose these backrefs.
• MM: bad idea, but - put WeakMap in each object, pointing to parent.
• BJ: WeakMaps don't work that way.
• KG / CW: keys are weak, not the value.
• BJ: GT pointed out there are weak refs in JS - but don't use them.
• KN: Thought about looking into that (finalizers) more deeply before deciding it was a terrible idea.
• CW: resolution: don't put back pointers to parents. Spec non-prescriptive about weak vs. strong refs. Beware, might be strong refs.
• BJ: that's what the text effectively says right now.

Agenda for next meeting

• CW: what about canceling next week?
• KN: Brandon, Myles and I talked about issues with error model. 1) problem where ErrorScopes are global state; await in ErrorScope can capture other work. 2) Two different widgets using same device and also using ErrorScopes because of conflicting with each other.
  • KN: working on proposal to fix this. Hopefully non-intrusive. Says: you can have multiple clients of the same device. Each has own Error Scope state. If you want 2 diff widgets doing their own thing - you fork it and it doesn't interfere with anything else. When you send it to another thread, you get another one. Not changing a lot.
  • KN: createView is associated with texture. If we describe it this way - no clear place for createView to send errors. No decent solution except to move createView back to the device. Also getBindGroupLayout. Don't want to move these, but maybe necessary to solve the problem.
  • KN: hopefully next week will have solution.
  • MM: why can't you report those errors to same place texture errors are?
  • KN: could. But, if you send texture to another thread, where do its errors go? Not associated with a specific device client.
  • MM: answer I'd propose - destination for views errors don't change when texture gets transferred.
  • KN: sending errors across threads then. Nothing strictly wrong with that, but…
  • MM: fair enough,
  • KN: hard problems, trying to work through.
  • BJ: I've been concerned too about moving createView. Keep coming back to the idea - cleanest way to make it clear where errors go is moving it to the device. Not a finalized proposal.
  • MM: this topic isn't just about ErrorScopes. Ramifications will be large - will affect multithreaded rendering on workers, and multi-queue. Trying to come up with minimal design to work with these. Don't have to design these, but want to find path forward.
  • BJ: in Kai's doc, I appreciate that each proposal's split up - here's what we have to do now, and here are the ramifications after V1. Don't want to solve the entire problem space right now.
  • KN: still working on the writeup.
  • CW: let's wait until it's posted to discuss it further. Concerned about ramifications - if we move createView, getBindGroupLayout - intricate changes to the spec.
  • KN: FWiW the designs I'm coming up with wouldn't cause a lot of changes now. But post-V1 would cause a lot of refactors.
  • CW: let's see once the doc's written.
• CW: should we cancel next week's meeting?
• KN: I think we'll be able to have a proposal by then. Also a few more discussions ongoing.
• MM: can talk about external textures next week too.
• CW: OK, we'll meet next week and end early if we run out of topics.