Skip to content

Minutes 2023 01 04

Jump to bottom
Corentin Wallez edited this page Jan 5, 2023 · 1 revision

GPU Web 2023-01-04/05 APAC-timed

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

Chair: KG

Scribe:

Location: Google Meet

Tentative agenda

  • Administrivia
  • CTS Update
  • “Tacit Resolution” Queue
  • Full burndown!
    • Make GPURenderPassDecriptor.colorAttachments optional #3701
    • 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
    • Dan Glastonbury
    • Myles C. Maxfield
  • Google
    • Brandon Jones
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
  • Intel
    • Hao Li
    • Jiawei Shao
    • Shaobo Yan
    • Zhaoming Jiang
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert

Administrivia

  • Remember to vote for the F2F dates!
  • KR: possible to add another week to the options? E.g. early March?

CTS Update

  • KN: working on code coverage tool for Dawn/Chrome when running CTS. Gyuyoung at Igalia's contract has ended, so officially no longer on CTS. Multiple folks on our team are picking up CTS work.

“Tacit Resolution” Queue

  • Make GPURenderPassDecriptor.colorAttachments optional #3701
  • Right now, can have no color attachments, but have to say so. Proposal to not have to say that.
  • MM: mechanically, no problem. Think most people will want them. Defaulting to a corner case seems backward. Not a formal objection though.
  • KG: I agree. I think it's OK to ask people to spell it out. False positive rate in people forgetting it.
  • KN: that was the original logic. Thinking more - don't think it matters much. You'll hit an error somewhere if you wanted color attachments and forgot them.
  • KG: can you tell because you attached to a shader which has color outputs, and get a validation error?
  • KN: beginRenderPass will error very quickly. Pipeline won't have attachments, shader will try to write them.
  • MM: do pipelines default to having color attachments?
  • KN: they're required in the RP.
  • MM: both optional sounds OK. I lean toward both being required.
  • KG: I think both should be required. Esp. if this is a source of black screen issues.
  • KN: I'm pretty confident you'll get errors in those cases, but no strong desire to do this. Wouldn't protect you if you forgot them in both the pipeline and render pass.
  • MM: that's my concern.
  • KG: think we're erring on the side of keeping them required. Let's do that, and close this for now.

Passive Fingerprinting Surface #3101

  • KG: not concerned about the # bits revealed in fingerprinting here (e.g. by limits), considering number of entropy bits exposed in other ways. Not sure how much we could do at the spec level. Our UAs are interested in reducing fingerprinting. Forcing it to be done in the spec is counterproductive.
  • MM: suggestion from a few months ago - implementers in this group agree on common fingerprinting buckets. Last time I brought this up, realized defining those buckets wouldn't be feasible for MVP. That's our preferred response.
  • KG: why do you want this across UAs?
  • MM: for same reasons the issue suggests.
  • KG: you can already tell browsers apart.
  • MM: agree.
  • KG: so why coordinate this across UAs? We've had to change the way we do bucketing in Firefox based on security bugs. Think it's harder than you might.
  • MM: think we should cross that bridge later. Can have longer discussion later when it's more relevant.
  • KG: Do other people also feel like this is maybe-hard to coordinate, or do people think it’s maybe-easy?
  • KN: Maybe-hard
  • (more discussion)
  • KG: what part do you want deferred?
  • MM: what's the particular outcome this topic's on the agenda for?
  • KG: I want feedback from other people that the thing I wrote accurately reflects our general consensus feelings. Half from my POV as Gecko impl, half trying to capture group's consensus.
  • MM: let's take AI to review this in more detail.

Permissions Policy for WebGPU and for unmaskHints #3483

  • KN(pretyped): have some feedback from our spec mentors. Also if we were to do user activation of some kind (see #3101) it could play in here
  • KN: gist of feedback: probably shouldn't spec a permission policy for something with non-normative effects. One I proposed says, if you don't have the permission, the browser may impose add'l restrictions in the iframe. Domenic said, if we aren't confident in spec'ing specific behavior, probably an interop risk to do that. Fair. People already have to deal with different device capabilities, so I think risk's reduced, but fair point.
  • KN: he did say, allowing top-level origin to restrict cross-origin iframes from doing things makes sense. Good to have the ability. Not sure how to limit it more tightly.
  • MM: is the scope of this issue just about interactions between frames & sub-frames? Or also including interactions with Permissions API or others?
  • KN: Don't remember what Permissions API looks exactly like. Allows a page to delegate caps to x-origin iframes it embeds. Also exists at HTTP level. We'd have a default to let pages use WebGPU. You can use headers to disable a particular page's WebGPU access. Don't know how this interacts with Permissions API. (iframe can check what's delegated to it.)
  • MM: Also gives code location for prompts to appear to user. Scary - already have such a place.
  • KN: if you requestAdapter multiple times, we'll prompt you on the first one. If you do permissions.request(), that'd count as the first one. MDN also says that's experimental. permissions.query() is the only one you can use. Others are deprecated?
  • MM: it's more interesting to us how it interacts with the permissions API than iframes.
  • KG: permissions policy's only for frame-to-frame.
  • KN: essentially yes. TR version of permissions API doesn't have anything except for query().
  • KN: also: Domenic said, if there were to be a prompt, you'd want a permission so host page can delegate to iframe the ability to show a prompt - important. But since we aren't planning for a prompt, not sure how we'd expose it.
  • KN: prompt I imagine - identify your machine. How'd you write it so a user can understand it? Wouldn't be WebGPU specific.
  • KG: have had 2 ideas - I want debug info for this machine because something went wrong. Or, something to give pages/origins unchecked access, like installed apps have root access. Not something we're pursuing though. Also, I don't think most apps that want the renderer info need to know specifically. Giving them coarse-grained info is good enough. I don't think there's value between the coarse- and fine-grained info
  • KN: for requestAdapterInfo I agree. But, exposing fewer features, a smaller adapter, or no adapter to iframes - seems generally desirable. Prevent embeds from doing "interesting" things.
  • MM: do implementers think iframes should get WebGPU by default?
  • KG: yes.
  • KR: nods.
  • KN: yes.
  • MM: I meant third-party iframes.
  • KN: I think so but no strong reason.
  • KG: reason in my mind - is this part of the web? Or, someday, will we have third-party iframes be lesser citizens of the web API? If no current plan there, not sure why WebGPU would have that plan. Everyone doing graphics might spin up WebGL instead of WebGPU.
  • KR: I think not supporting webgpu by default would damage ecosystem for e.g. sketchfab on twitter etc. I think we should have webgpu avail by default, shouldn’t segregate it off. It's primarily a visualization API.
  • KN: fair point. Didn't think about iframes already existing and not delegating this permission.
  • KG: any stakeholders left standing that want us to do a permissions policy for WebGPU V1? Fine if not.
  • KN: not 100% sure personally. Despite concerns with my proposal I still like it - like having the option even if it's a slight interop risk. Better than the backward compat risk if we want to add it later.
  • KG: then the question is, are we adding a skeleton that doesn't do anything right now?
  • KN: wouldn't want to do that - same as not doing anything. People would have to implement something. Maybe you only get a core adapter.
  • KG: doesn't really address abusive capabilities spec. Mainly talks about compute shaders.
  • KN: think I'm happy to not do a permissions policy. Will follow up with folks I was talking with.
  • KR: Things that we’ve tried to lockdown in webgl are like, access dgpu from 3rd party iframe. We’ve changed policies on devs, maybe didn’t have a big impact because it’s just perf/power. [version numbers in webgl?] Adding a Perm Policy is probably worth it to allow people to opt-in to e.g. more-power-use if they want.
  • KN: in Chrome we have had to add mitigations to existing APIs. Like, we detect ad iframes, and put limitations on it. Can do this heuristically. Has been proven out with past APIs. Not sure how critical it is to do better than previous APIs.
  • KG: concerned about taking away tools from people if they're worried about their use in an iframe. A lot of uses of WebGL that aren't obviously WebGL. This app doesn't work anymore, why? Give us your preferences list, they disabled WebGL. Do you want people to develop a non-WebGPU version because it might be forbidden in iframes? If we're concerned about e.g. compute shaders we could potentially split that off, but don't think it solves the problem that much.
  • KG: power usage - containing doc maybe knows how much power inner documents/iframes should be able to use. Ad networks shouldn't be able to consume 100% GPU, etc.
  • GT: Kai brought up idea, main page can only use CPU-emulated version of WebGPU. That's more power, not less. Not a win for the main page. Pointing that out.
  • KG: I'm thinking iGPU vs. dGPU mainly.
  • KN: reason for CPU was for privacy, fingerprinting mitigations. Happy to say fingerprinting mitigations shouldn't be a goal of the permission policy.
  • KG: permission policy for power use? Discuss? Goal for this issue isn't to have something to have a permissions policy for, but address the line item of abusive capabilities. If we don't think we need to do that, we should remove it and instead file an issue for e.g. power usage.
  • KN: agree with closing this based on that outcome. Possibly opening a new issue.
  • KG: think it's worth writing down the resolution.
  • MM: to confirm - there will be no tokens that a parent frame can pass to a child frame to delegate WebGPU specific permissions.
  • KN: we won't have one which lets you delegate "fingerprinting capability". Might consider one for power use.
  • MM: OK. If someone comes later with new arguments, this issue could be reopened? Not making a philosophical decision, but a "for-now" decision?
  • KN: yes. Planning to get more feedback before settling this forever.
  • KG: this is however the last call for V1 on this topic.

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

  • KN: discussed this in multiple meetings. Minuted resolution - say it's invalid to do this, but not validate it. Somewhat-undefined behavior if you alias writable storage buffers. Concerns about writing "undefined behavior" in the spec. And, having this be undefined at all. Should discuss again.
  • MM: new context - now, in the shading language, there's a resolution to have static analysis ensuring pointers don't alias. This particular issue is the API analogue to that issue which has a resolution.
  • KG: if people are comfortable, think it's fine.
  • KN: what was the WGSL change? Allowing variables to alias? Suggestion is that the API also allows variables to alias?
  • KG: think so.
  • JB: there's an analysis in WGSL preventing variables from aliasing, right now. That's a different kind of aliasing - aliasing of pointer arguments.
  • KN: OK. Thing David linked to is something different. https://github.com/gpuweb/gpuweb/pull/3581/files
  • MM: unstated - pointers in shading language & pointers to buffers in bindgroups should be considered the same. They're just pointers.
  • JB: since we took steps about this in the shading language you're saying to do the same thing at the API level?
  • MM: yes.
  • JB: it's zero overhead at runtime in the shading language. Here, the validation would be per-draw-call, expensive. Not sure how that was resolved.
  • MM: resolution there was - we did not agree whether the cost was worth the benefit. Spec'll say it's illegal, but not validated.
  • MM: imagine a shader, 2 RW buffers. At runtime, they alias. End up writing to one, assuming the other didn't get modified.
  • KN: WGSL spec says - it's a dynamic error if you have 2 resource variables that are mutable with overlapping memory.
  • MM: what's the analysis Jim and I are remembering?
  • JB: it applies to pointer arguments to user-defined functions. Sounds to me - WGSL already addressed this question. Decision was - pointer args can't alias. Global variables to buffers - if they alias, you're on your own.
  • MM: don't remember that.
  • KN: this WGSL change was in November.
  • JB: a dynamic error permits impls to detect it, if they like.
  • KG: more like user error.
  • MM: boils down to - can a dynamic error make us invalidate the command buffer?
  • KN: don't think so. Would have to write that on the API side.
  • JB: dynamic errors can't invalidate the command buffer. They show up once we're running the code.
  • KN: yes, but could cause the draw call to not happen.
  • MM: could cause previous draws to not happen. When you encode the command, detected as programmer error, could invalidate command buffer.
  • KN: why do you want that?
  • MM: for earlier example. Because compiler doesn't know things alias, RWs don't seem coherent.
  • KN: consequence?
  • MM: wrong results. Could lead to more dynamic errors.
  • KN: WebGPU's not free of wrong results.
  • MM: not sure I agree with that - possible to write a (...) program in WebGPU.
  • KG: idea is that if it runs on your machine, it's likely to run on others.
  • KN: lots of things in the spec where we can't guarantee how they work.
  • MM: I'm assuming pushback is because of performance. If we could quantify the perf cost, that would help me change my mind.
  • KG: not just perf cost, also functionality. Imagine 2 structured bindings, on one, only access evens - on the other, odds. Hardware supports it. If you do this interleaved aliasing - technically safe. But, our naive rules couldn't differentiate from a "real" aliasing that breaks. Forbidding aliasing also forbids benign aliasing.
  • MM: in comparison - what happened with uniformity analysis?
  • JB: lot of discussion.
  • KG: there are multiple opt-outs. Finished them in Dec 13 meeting minutes.
  • MM: maybe some way for author to say, I know my bindings alias.
  • KR: the major concern about putting this in at all is the perf cost. Per-draw-call validation is a major bottleneck in WebGL and we don't want to introduce these in WebGPU.
  • KN: the english-language algorithm: https://gpuweb.github.io/gpuweb/#abstract-opdef-encoder-bind-groups-alias-a-writable-resource
  • JB: indirect draw calls? How would the analysis work? Thorny. Couldn't do that until you have the contents of the buffers in hand.
  • KG: depends on what level we're doing this. If you alias sections of the buffer - we can determine that.
  • KN: can set pipeline and bind groups, then draw as much as you want. Most times, not a lot of draw calls per bind group.
  • JB: what about dynamic offsets? Are they OK too?
  • KN: that'd also invalidate the validation.
  • JB: sounds really thorny to me.

Agenda for next meeting

  • Non-APAC time.
  • Have had these last 2 meetings accidentally at 5 PM again instead of 4 PM. Do people want to go for 4 PM timeslot?
    • RC: I'd prefer the 4 PM timeslot.
Clone this wiki locally