Minutes 2023 01 18

GPU Web 2023-01-18

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

Chair: Corentin

Scribe: Ken

Location: Google Meet

Tentative agenda

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• Passive Fingerprinting Surface #3101
• Permissions Policy for WebGPU and for unmaskHints #3483
  • Permission Policy for WebGPU power usage #3751
• 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
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Shrek Shao
• Microsoft
  • Rafael Cintron
• Mozilla
  • Erich Gubler
  • Jim Blandy
  • Kelsey Gilbert
  • Teodor Tanasoaia

Administrivia

• MM: Reply to Myles' email if you're planning to attend the F2F
• MM: Any ideas for group dinner locations?
• MM: ~24 people signed up right now, 5 virtual. 48% Google, 22% Apple, 13% Mozilla, few others.
• Agenda for the F2F
• MM: would like to discuss shading language stuff in AM - have a remote attendee from Europe. API discussion we'd prefer in the afternoon (?) - have attendee in Australia.

CTS Update

• KN: our team's working on CTS. Loko, improvements to texture helpers. Shrek, texture helpers - depth, stencil, multisample, and writing tests using them.
• Gregg found lots of issues in Chrome's implementation of canvas. Bunch of new reftests, etc. currently broken on Chrome - great progress.
• CW: Bunch of additional WGSL tests. Validation of @align, builtin/test. Finding spec issues.

“Tacit Resolution” Queue

Passive Fingerprinting Surface #3101

• MM: would prefer if you postpone this topic

Permissions Policy for WebGPU and for unmaskHints #3483

• Permission Policy for WebGPU power usage #3751
• KN: only sent internally yesterday; no responses yet. Thought a lot while composing the internal email.
• KN: having a hard time finding a way for us to add permissions policies for either.
• KN: gist of permissions policy: allow top-level page to delegate some special permission that it has from being the top-level page, and delegating that to an iframe. We have no such capabilities - no permission prompts like "wants to access your location".
• KN: we do have conceptually e.g. "wants to use high power" or "wants to fingerprint your machine", but these don't exist.
• KN: considered Ken's concern - existing embeds like Sketchfab currently have full WebGL access (or can have full access). They already exist, and won't all get updated. If we restrict WebGPU in that iframe, Sketchfab wouldn't be able to upgrade to full WebGPU for that existing iframe. For backward compat reasons, doesn't make sense for us to put major restrictions on what you can do in an iframe with WebGPU.
• KN: we could still do this for e.g. high-performance. Limiting access to discrete GPU's less drastic than giving you a "core" or software device. But if we do this we should do it in the future, across WebGL+WebGPU at the same time. Can't practically solve this now.
• JB: if you change the default from disabled-for-subframes to enabled-for-subframes, that makes the compatibility story easier.
• KN: yes, you can default to "*" instead of "self" - iframes will get them by default. Embedders get the ability to disable things inside iframes. Can do this after V1, and can discuss, but issue's no longer blocking.
• JB: only pre-V1 if we want to default to restrictions.
• KN: agree.
• MM: we're mostly interested in this because of privacy, not security. Security has to be enforced regardless. Interested in trackers+ads. Most of these aren't embedded in outer page via an iframe. Top-level page says "script src=...", and script creates an iframe itself. Ad/tracker can add any attributes it wants to the iframe. It's our opinion that this mechanism, in the area we're most interested, will not be effective. We're interested in other kinds of solutions. Either by UAs setting the rules, or permissions policy.
• KN: yes. Didn't go into every detail of my big email but that's one of them. This doesn't' really do anything for ad networks because they don't work by writing an iframe on your page. Chromium heuristically detects ad iframes, and use this for mitigations - limiting access to certain things we think are ads. This is a more sound approach, though it's heuristic.
• KG: sounds fine to me. Sounds like we don't care to pursue this iframe idea, so we can stop discussing it.
• CW: does anyone care to continue this topic? Chromium doesn't, WebKit doesn't, Mozilla doesn't. We can care about this in the future and offer disabling of features then.
• KN: does anyone care about the power topic? There's a permission for using the discrete GPU, the top-level page might have it, the iframe might not, depending on defaults. Ken mentioned limiting third-party iframe access to discrete GPUs.
• MM: Another access might be base limits / base extensions.
• KN: I'm just talking about ignoring the high-performance power preference.
• MM: few axes we can discuss.
• KG: not sufficient to solve this for iframes. Think we've considered this, came from TAG recommendations, and we decided not to do anything.
• CW: people OK saying we won't do anything for iframes?
• KG: would like to pivot the power-preference discussion to not talking about iframes.
• CW: close 3483. KG you'd like to use 3751 to talk about origins?
• KG: yes, but maybe not for V1.
• KN: agreed.
• CW: consensus: we're done for V1 in this area.

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

• CW: recap: Google pushed back against the validation. For V1 we can have the validation, and if people complain, we can remove it. We're willing to add it.
• MM: there were 3 different options. Validation; allow to alias, but have semantics be well defined; and you're in undefined area if they alias.
• CW: semantics well defined is impossible. It's not the hardware, it's the compiler. Talked with Alan Baker, memory model expert. coherent keyword only works for single binding point. Loads will look at the write queue. Slower on some hardware, doesn't matter. Two different binding points - compiler might examine code, two different binding points, independent, can reorder things as I like. Semantics change then. Nothing we can do about this.
• MM: I see. Any link where I can read about formal definition of coherent?
• CW: you can look at Vulkan spec. Asked Alan once I couldn't understand.
• MM: OK.
• CW: if people complain about runtime cost we can reconsider.
• KG: if you want to avoid costs, you can inline all bindgroups together. Checked at BindGroup creation time.
• MM: you're talking about app, not the implementation?
• KG: yes.
• CW: so you're saying validate at BG creation and draw call?
• MM: no, you're already doing that. Create BG; 2 obviously-conflicting resources. You can clearly detect that at BG creation time.
• CW: spec doesn't mandate it.
• KG: no, but we'd do it.
• MM: that's the core of why I think the validation won't be that bad.
• KG: so we're checking all the bind groups against each other. Lighter-weight than WebGL.
• KN: slightly reduces amonut of draw time validation but not that much. Instead of NxN you have Nx(number of things in bind group). Still quadratic.
• MM: can sort, then do binary search rather than linear scan.
• KG: don't have to put everything in same bind group. All buffer bindings in same bind group, they're pre-checked.
• KN: can prebuild sets, check for set membership.
• KG: also, in WebGL, hard to do anything faster than checking buffer object and its length. Don't need to do that pointer chasing anymore. Everything inline in bindgroup. Should be cheap.
• KN: hopefully.
• CW: for V1, in Chrome, we might do the quadratic thing and figure it out later.
• KG: we do something similar for index validation in WebGL and never did anything better because it works.
• CW: OK.** Resolution: will take this validation, taking into account buffer ranges.** Only draw call time, not bind group creation. There's implementation choice. I asked Raph Levien but no answer yet.
• MM: so if you create a bind group with two things obviously colliding, we won't fail BG creation but will fail later draw calls with it?
• CW: yes. Can currently add 2 TextureViews in same BG that conflict for example.
• MM: if you have 2 seemingly conflicting things, e.g. one in vertex shader and one in fragment shader, those don't collide.
• CW: correct.
• KG: we don't do vertices while doing fragments?
• KN: don't think that's true. VS/FS can be interleaved.
• MM: will be on Apple Silicon.
• CW: similar to two draw calls using same storage buffer on different bind points.
• KN: shader execution problem. I agree then.
• CW: even FS invocation writing to memory, if it loads same memory from different bind point, it still might get different data. This validation prevents that.
• TT: storage textures - should we do the same thing for those?
• MM: think so. Conceptual difference: telling that ranges of 2 buffers intersect is one comparison. Two TextureViews of two textures intersecting - two comparisons.
• TT: spec currently says storage buffer and storage textures can alias - would be nice for both to behave the same for storage textures.
• CW: agree.
• KN: spec we wrote has both storage buffers and storage textures.
• Discussion. No error at BindGroup creation time. Save state if an obvious aliasing.
• KN: so, just remove the part of the spec saying it might be an error.
• CW: and add algorithm steps for storage textures.
• KN: spec already does this.
• KG: does it do it by texture level?
• CW: must be subresources. Whole level is bound.
• KG: sounds good. People will be less happy with this, but we already do this for WebGL.
• KN: OK.

Agenda for next meeting

• Remaining V1 issues!
• CW: I won't be here for next week's meeting.
• KG: I'll run it. Normal time slot.
• KN: there's one new thing, will write it down here.
• Agenda
  • Use automatic expiry for imported textures, remove .expired #3633
    • editors will also discuss first
  • copyTextureToBuffer, should we add native API limits or workaround them? #3729