Minutes 2023 01 11

GPU Web 2023-01-11

Note that unless stated otherwise this is a GPU for the Web community group meeting and not a working group meeting.

Chair: CW

Scribe: KR

Location: Google Meet

Tentative agenda

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• D3D12 does not support copying between textures of different dimensionality #3723
• Metal doesn't allow writing frag_depth without a depth attachment #3728
• copyTextureToBuffer, should we add native API limits or workaround them? #3729
• Passive Fingerprinting Surface #3101
• Permissions Policy for WebGPU and for unmaskHints #3483
• Should the API enforce that writable storage buffer bindings don't alias each other? #1842
• Agenda for next meeting

Attendance

• Apple
  • Mike Wyrzykowski
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Ben Clayton
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Shannon Woods
  • Shrek Shao
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
  • Teodor Tanasoaial

Administrivia

• CW: Please add agenda items to
• Chrome got approval from its API owners to ship WebGPU! (When the team feels it's ready)
  • Thank you all for your support on the various standards positions!
• New member from Apple!
  • Mike W - working on WebGPU pipeline implementation in WebKit!

CTS Update

• KN: gman@ writing a bunch of reftests. Finding things that don't work correctly in Chrome. Corentin too. Lots of additional regression tests and coverage.
• Loko working on fixture-level stuff to simplify helpers.
• Shrek finding problems and writing tests.

“Tacit Resolution” Queue

• Empty!

D3D12 does not support copying between textures of different dimensionality #3723

• Assumed you could copy between 2D / 2D Array / 3D textures. Not guaranteed to be portable in D3D12. It's a queryable feature in recent D3D12 versions. Could:
  • forbid by validating it out
  • make browsers polyfill out of it. Allocate buffer, bounce the copy through it.
• MM: if in the future we won't have this restriction then we should polyfill. But if never supported on some vendor's devices, should forbid it.
• CW: Devices which support D3D12 also support some other API which does support this.
• RC: I do think that this option will be universally available over time. We didn't write conformance tests for this, and we found that some hardware didn't implement it reliably.
• MM: sounds natural. Let's say it's allowed in WebGPU and have a slow path temporarily.
• CW: sounds good.

Metal doesn't allow writing frag_depth without a depth attachment #3728

• CW: doesn't make sense, so we should validate it out. Counter-argument: WebGPU allows frag shaders to write to color attachments not present. <shrug> But these are different than depth buffers. Validation error for frag_depth?
• KG: possible to do in a memoryless way? Allocate a memoryless attachment and attach it?
• MW / MM: don't' know why that wouldn't be possible.
• KG: seems easy then.
• KN: couple problems. When we create the render pass we don't know what pipeline'll be used by it. Necessary to fake depth attachment? Don't know. Could always do that if it's free because it's memoryless. Will still take from on-chip budget. Might be compatibility problems using one pipeline having no depth, and we fill it with depth24unorm, and another one which uses depth32plus, and you can't satisfy both in the same render pass.
• KG: more general problem.
• CW: memoryless works on tiled GPUs, but Metal works on immediate mode GPUs too.
• MM: "memoryless storage mode is available on Apple family GPUs."
• CW: here, it's validation of shader module against pipeline. Format doesn't matter - has to match between pipeline and render pass. Think all of this means the two solutions are (1) validation or (2) shader transformation to remove frag_depth sometimes.
• CW: can we say it's a validation error for now?
• KG: sure.
• MM: second option - can't do a compiler pass because we won't know when we're doing codegen what the render target formats are. But would be possible to do with Metal function constants. Can make these things conditionally present based on function constants. Think both options are viable.
• MM: I'll provide a link into the Metal shading language spec describing how to conditionally make a member of a struct present.
  • CW: 5.8.1.6 Function Constants with Elements of a Structure
• CW: OK. Still, can we say this is a validation error to start?
• MM: that's OK too.
• MW: that'd be preferable.
• KN: would like to have this written down in case we have to revisit this in the future.
• MM: should we do the same thing for color?
• CW: we checked and it worked portably for color.
• MM: for consistency.
• KN: think that'd be unnecessarily punishing for developers. Think they use it.
• KR: Think developers do this frequently. Found this use case when adding MRT in WebGL. Developers will generate an uber shader and forget about this.
• CW: OK. Consensus - validate out for frag_depth, continue to allow writing nonexistent color attachments.

copyTextureToBuffer, should we add native API limits or workaround them? #3729

• GT: Metal has a limit. Have to pass bytesPerRow - can't be bigger than max texture dimensions. Can work around by copying row at a time. Already in Dawn. Should we pass that limit on or continue to work around it?
• KG: thanks for bringing it up. I think we should work around it.
• KN: copying each row's not terrible. Lots of copies, but better than going to another buffer. Concerns from Apple about perf penalty?
• MM: don't think it's that big a deal.
• CW: OK. Can always emit warnings.
• Consensus: no added validation.

Passive Fingerprinting Surface #3101

• CW: Yoav Weiss pointed out this is actually active. From last meeting, Myles wanted more time to think about it?
• MM: yes, but still do.
• CW: overall, think we should target closing the V1 issues by or at the F2F. Gives us time including for meta-issues like this one.
• MM: sounds good.

Permissions Policy for WebGPU and for unmaskHints #3483

• CW: hard to understand the status based on the minutes.
• KN: apologies. I didn't do requested homework. Did get another contact for people to ask questions. Left off - trying to figure out whether permission policy makes sense for something not normatively defined. Also some internal discussions about permission prompts. Right now Chromium has put in an exception - if you call requestAdapterInfo with any hints, we say this isn't implemented yet. Don't know whether we plan to prompt for that yet. Exception is more future-proof. We weren't giving extra information anyway. Not likely we'll give more information based on the hints in the future.
• CW: for iframe sandbox attributes then, do we have a way forward?
• KN: still need to do research. Feedback so far, using permission policy for non-normative behavior is not preferable. And that's the proposal I had earlier.
• CW: proposal - Allow attribute based on everything above. How to close this issue in finite time?
• KN: my homework - talk to more people. I will.

Should the API enforce that writable storage buffer bindings don't alias each other? #1842

• MM: question is, imagine you have a BindGroupLayout with 2 buffers in it. Can you create a BindGroup where they point at the same resource? And, say you have 2 different BindGroups, can you have a buffer in one that points to the same resource as the other, and bind both at the same time?
• CW: when you say bind the buffers - at granularity of draw, or usage scope?
• MM: I assumed at the draw level.
• KN: at draw level. Concern - breaking invariants of the shader, not races between different draw calls, which we already allow.
• MM: reason this is interesting - we have policy in WGSL, two pointers coming into the same function can't alias. Same issue, but tradeoffs are different. WGSL, we can verify at compile time. If we want to make sure 2 resources don't point to the same thing, has to be validated at draw call time.
• CW: usage scope boundary is cheaper but harder. Prevent aliasing/races - hard to reuse the same buffer between draws. OIT using linked list in storage buffer, would be hard. Do we know why WGSL decided to not alias things?
• MM: in languages like C++ that have pointers, aliased pointers are still correct. Wanted to make sure same is true in WGSL, but via different mechanism.
• KG: I thought it was a dynamic error.
• JB: we forbid it, but may expand the semantics in the future.
• CW: how much of this is for workgroup / private / global variables, vs. storage uniform variables?
• MM: workgroup variables can't alias.
• CW: but pointers-to can?
• MM: inside WGSL, just resolved - no such thing. (if i remember correctly, i’m a bit rusty)
• CW: OK. Worry is - same as when issue was posted - devs will want giant storage buffers, indexing in to get the data they want, reinterpreting it. Maybe they have another one. Input/output of shader. Sometimes it's the same buffer at 2 different offsets. Hard to tell developers things don't work because they placed memory next to each other.
• KG: we could write rules for this.
• MM: last week - discussed forbidding aliasing. Our position - a program that may/may not have aliasing should be well defined. Can forbid via validation rules. Or, if you have the same resource bound in 2 different places, write through one variable and read through another - you get the same answer.
• CW: that's like GLSL's coherent qualifier. Pipeline would always need to tag buffers as coherent. Seems very expensive if all shaders have to have it. We already have data races. Recently someone used compute shader, 4 instances writing to 4 components of a vec4. Bad data. Granularity of mem write was 16 bytes. One overwrote the others. Can already race with yourself. As long as people use aliasing buffers but don't race on the same memory locations, they're well defined. You can already run into this issue with a single buffer. What's the point?
• KG: fewer footguns are better.
• MM: issue #1621. Should WGSL expose the content of coherent buffers?
• CW: there was a WGSL discussion about it.
• KG: programs are less well-defined if we allow this aliasing. We can allow it but make it more well defined. Or forbid it.
• MM: those are the 3 options.
• KG: Worried that the more footgun like this we have, the more non-portable behavior we may have between hardware and browsers. Would like fewer of these if tolerable for developers. Think we can ask developers to have subranges be disjoint.
• MM: Sounds right.
• CW: seems expensive to validate.
• MM: not sure it is very expensive. Will cost > 0 time, but - wanted a demo project by this time. Didn't finish it in time. Would like to postpone the "how expensive is it" discussion.
• CW: we keep adding more draw-time validation.
• KG:
• CW: it is a developer obstacle. They'll want giant storage buffers.
• KG: to convince the rest of the group that they shouldn't worry about the soundness of programs…
• CW: WGSL already decided all buffers are coherent. #1621. Compute shaders - if you write to a buffer, aliased buffers will see the result. Seems no portability hazard if we allow this, if I understand #1621 correctly.
• MM: WGSL itself, coherency is unobservable. Only issue is aliasing. Agree with your reading of this issue - buffers should be treated as coherent. That solves our desire of making this well-defined. So, conclusion - given #1621, aliasing should be allowed, and well-defined as per the coherent keyword.
• CW: I think so. Would like to check the semantics with Alan/David.
• MM: Metal compiler will in some situations assume things don't alias. Can get into more detail for implementers. There are ways around them - not unimplementable.
• KG: please check privately with Alan/David and come back with a result.
• CW: will do.

Agenda for next meeting

• CW: same 3 issues. More if more come up. Will try to make progress on coherent thing.
• KN: think can work on permission policy thing.
• MM: I'll work on fingerprinting surface.