Minutes 2022 10 05

GPU Web 2022-10-05

Chair: CW

Scribe: KR

Location: Google Meet

Tentative agenda

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• Require effective storage buffer binding size be a multiple of 4 #3477
• createPipelineAsync() doesn't reject its promise, even if the created pipeline is invalid #3296
• mapAsync(WRITE) zero-fills the relevant region of the buffer #2926
• Canvas texture expiry timing is unpredictable #3295
• Just-in-time: Internationalization Metadata for Human-readable Messages #2780
• (stretch) Passive Fingerprinting Surface #3101
• Agenda for next meeting

Attendance

• Google
  • Brandon Jones
  • Corentin Wallez
  • Kai Ninomiya
  • Ken Russell
• Microsoft
  • Rafael Cintron
• Mozilla
  • Erich Gubler
  • Jim Blandy
  • Kelsey Gilbert

Administrivia

• Moving more meetings to APAC to accommodate
  • CW: generally sounds fine. Ben Clayton and myself can't attend.
  • We will reach alignment internally in Google ahead of time.
  • If Apple's not represented it'll be hard to make progress.
  • KG: Apple might be able to make the non-APAC time slots. Maybe easier to do so if there are fewer of them.
  • CW: every other one APAC / EMEA?
  • KG: 2:1 would be one APAC for every two EMEA.
  • CW: could work.
  • KG: will reach out to them with you.
• KN: when is Myles leaving?
• KG: Nov/Dec.
• KG: only 1.5 months we're missing due to December holidays, and Thanksgiving as well.
• KN: could perhaps move all of those meetings to APAC.
• KG: nicer to not do that.
• CW: let's sync with Myles.
• CW: Charter discussion?
• KG: someone on Mozilla side wants to look at CG charter addition.

CTS Update

• KN: the usual, plus Loko's going through Needs-CTS issues in repo, make sure they're filed. Large backlog of these. Making sure we're not duplicating tests.
• BJ: trying to get Dawn running on Android. Testing on Pixel devices, both ARM Mali and Qualcomm Adreno GPUs. Encouragingly, a lot runs out of the box. So far, nothing that would inform a WebGPU spec change. Also, good performance all around.
• CW: nice. Fingers crossed we don't need to change the spec.

“Tacit Resolution” Queue

• KN: Gyuyoung ran into some of these while writing tests.
• Don't throw exception when getBindGroupLayout index > maxBindGroups #3506
  • KN: right now, 2 redundant checks. # bind groups, and # bind groups in the pipeline. Gets rid of the first one. getBindGroupLayout returning a new object each time makes this easier.
• Don't trail with empty BGLs in default pipeline layout #3505
  • KN: algorithm issue. What to do with bind group numbers that aren't used. Post-V1. But hadn't done anything about bindgroups at the trailing end.
  • If you use 0,2 - we'll generate 0,1,2, but not 3. Won't need to generate empty bindgroup to use the implicit layout.
• Only allow defined GPUShaderStage bits in bind group layout entries #3500
  • Don't put random bits in shader stage visibility that don't mean anything. Already have this for buffer and texture usages, and color write.
• Only allow defined GPUMapMode bits in mapAsync() #3499
  • Same thing as above, make sure we fail if you pass in bits we don't recognize.

Require effective storage buffer binding size be a multiple of 4 #3477

• Waiting for Rafael to get info from D3D12 team.
• RC: talked with them, they said they were OK with the proposal. Go ahead.
• KG: if you had 64-bit support in UAVs for example. Does that need 8-byte rather than 4-byte handling?
• RC: could you write the issue you want clarification on?
• KG: sure.
• CW: should we resolve this now, or do you think what we'll do will change?
• KG: should probably ask and then take this change. MSFT is happy with it as a whole, inspires confidence.
• KN: if requirements show up in the future, we can deal with them later. Put a flag, these should be aligned to 8 bytes appropriately. Not too worried about future-proofing this.
• KG: OK, let's take this.

createPipelineAsync() doesn't reject its promise, even if the created pipeline is invalid #3296

• KN: KG, the plan was for you to put together a proposal.
• KG: one more week please.
• CW: we can wait another week but the reject option seems good enough. I think we should aim for a high bar of good enough. There will be quirks in WebGPU anyway. Rejection could have some quirks but it's fine. What we have already is fine too. Simple change. Bigger changes are worse.
• KR: last week Myles said he was convinced by my flakiness argument.
• KN: KG, aside from interest in seeing your proposal, he didn't say he wouldn't be happy doing this.
• CW: let's try to gain consensus offline if we can.

mapAsync(WRITE) zero-fills the relevant region of the buffer #2926

• CW: discussed offline, think we shouldn't change anything, but we'll discuss with Myles in the room.

Canvas texture expiry timing is unpredictable #3295

• CW: Brandon you made a proposal.
• BJ: first, title in agenda not quite right. Canvas texture expiry in general.
  • (KN: fixed)
• BJ: previously: wanted these to expire on microtask boundary. Kai, Myles and I discussed. Myles' argument persuasive. If implicit presentation - should match expectations coming from other canvas APIs. Tricky because those aren't perfect fit for WebGPU. Hard to do lot of Canvas 2D rendering with part in microtask, and have only half of it show up. Implicit guarantee - from event processing, etc. - your drawing in tasks+microtasks will show up together. Unfortunate if we break this for WebGPU.
• Summary of comment in the github issue:
  • BJ: iterated on this. This AM - seems reasonable - came up with this:
  • BJ: if you look at task processing in HTML spec, everything gets put on its own task queue. Things grouped together like keyboard input. Reason: browsers should be able to give queues priority as necessary. So that mouse/keyboard input can have higher priority for example.
  • BJ: what if expiration was scheduled as a task on its own texture expiration queue? Strongly encourage browsers to give this fairly high priority. (Is Kelsey laughing? :) )
  • BJ: probably inappropriate that this task queue gets higher priority than others. Reasonable to say - we encourage browsers to do this with reasonably high priority. Specifically, encouraged to execute them before the next thing that'll create JS callbacks.
  • BJ: then - texture lives for entirety of task. Nothing about weird refcounting with microtasks. It'll be guaranteed to live for your task. Expired soon after.
  • BJ: pretty lightweight for browsers to handle.
  • BJ: doesn't require us to invent new language/mechanisms. Using well understood mechanisms, and nudging browsers toward a priority preference.
• KG: all to avoid commit()?
• BJ: yes, to some degree. Preference to say - we'd like to introduce explicit swap later. Discussed in past - don't want to do anything breaking current patterns too drastically for canvas APIs. Wanted implicit commit first. This is a way to get there in a better specified way. Post V1, can discuss explicit commit. Think it'd be valuable. Esp as we see more ports via WebAssembly.
• KN: also as we see Wasm Promise Integration proposal come online.
• KG: concerned that it's different from what WebGL does.
• BJ: that's a fundamental problem. WebGL's not well spec'd in this area. Technically is probably different from what WebGL impls do - but for side effects for users, gets closer than microtask-oriented solutions.
• KN: think it's not too far off from WebGL. Forgot - we'd queue a task that expires the texture, and also when we present it. Expectation, those two will look the same to users. They can't tell the difference between something happening in a task or between tasks. In WebGL, spec says roughly - when you exit the task, not guaranteed you can still see the texture. That's because of the way the event loop works. Between every task there's a possibility of presentation. By also expiring in a task, we make it expire regardless of whether we present it. And it does so sooner. If you get a texture early in the frame, it'll get terminated early. Can't rely on that in WebGL per spec, so it's about the same thing.
• KG: but we're making a new thing that probably expires things earlier. Want roughly to do the same thing that WebGL does. Another option - if you want implicit presentation, we do something different? Trying to
• KR: HTML spec authors gave us feedback not to do commit() on OffscreenCanvas. We’re almost there on this spec. Let’s do something that is better defined without a big change. I don’t think it’s hard to spec or implement.
• KG: making a new task queue…don't know how to do that.
• BJ: most specs do that. We say "WebXR input events task queue" for example. That's it. Becomes one of the group of task queues that are processed.
• KG: my POV - you're saying do harder than an API that works already. More accurate, but may break more content. Impl's something I'm not familiar with and can't comment on.
• BJ: see where you're coming from. My perspective a little different - we have behavior most people are OK with, but is ill-deifned. Can we use language of web specs to …
• …more discussion, too much interruption…
• BJ: think with task priorities we get close to what you're talking about.
• KG: think you're spec'ing something poorly defined that's not testable.
• BJ: think you're saying, spec it poorly defined because that's the way we did it in the past. Trying to find approach we can take which is less reliant on formal spec language, and achieve the same thing.
• KR: breaking things on task boundary will let you test - for example setTimeout(0) can assert that you get a new texture.
• BJ: want something reasonable, predictable, works across the board. Expiring at task boundaries gives us it in whatever web context you want.
• KG: want to hear Apple's perspective.
• CW: can you talk with other Mozillians?
• KG: that's not the issue - think this s less useful.
• BJ: can you give a test case this would break?
• KG: … think it’s more likely to break things
• KN: think it’s equally likely.
• CW: WebGL, at random times can get a new texture. Idea is - in WebGPU, try to define it - you can't render for more than one task. Sorry. Instead of apps being flakily broken when the compositor runs - make WebGPU consistent, no, you can't do this because it breaks sometimes.
• KG: think it'll be no less flaky. Want Myles' feedback.
• KN: think that's accurate. Browsers should do this. Not guaranteed to be less flaky. But an expectation that we'd try.
• RC: if someone uses a lot of microtasks and draws in each one, does the browser compositor have an obligation to show each one? Or just the last?
• BJ: good to clarify. In this new proposal, we're talking about tasks, not microtasks. If you have a task where you getCurrentTexture(), and schedule a bunch of microtasks - and call getCurrentTexture in each, and draw something new - under this proposal, you're guaranteed to get back the same texture for every microtask part of the same task. If you do load instead of clear for color attachment - all those microtasks can accumulate content onto the same surface. Once task's completed, opportunity to do the rendering. Something Myles was very concerned about being guaranteed. Didn't want difference in behavior - expiring on microtask meant you could get texture in microtask did some drawing, and now you get a new texture in a subsequent microtask. Not a danger in this proposal - addressing Myles' concern.
• KN: never an obligation to present oen of these textures. Can always skip it and present the next one.
• RC: so this is talking about which texture you get back, the same one or a cleared one. And if you get a cleared one, browser's still not obligated to show all of them.
• KN: exactly. Bunch of tasks in one frame - each one will get a new texture, and browser might only show the last one.
• BJ: similar to WebGL. Can render in mousemove - you can draw bunch of content that might not be drawn.
• RC: so for this proposal, for mousemove - will you get back a new texture each time?
• BJ: proposal will say, the browser should. Hard to require. May enforce restrictions on something in the core HTML spec. Reasonable interpretation - you'd get new texture in each task.
• KN: think most of what we're talking about is similar to Myles' suggestion to expire after microtasks are completed. Similar things. Just different ways of expressing it.
• RC: low-latency canvas / desynchronized: if you put this in, does it decouple things even more? Do what you want with this texture?
• KN: don't think we'll do desynchronized the same way as in WebGL. similar but not exactly.
• CW: need Apple to get consensus anyway - need to get back to this. Would like to get to next agenda item.

Just-in-time: Internationalization Metadata for Human-readable Messages #2780

• CW: INTL WG feedback.
• CW: We could live with having lang/dir (??) on device, or navigator even. Comfortable with this? Or would you rather wait for cohesive thing from INTL WG?
• KG: need to find a specialist at Moz. Don't find this super compelling. Not about localization, according to latest comment? As long as we don't need to put lang/dir on everything.
• KN: think this is a compromise that doesn't make sense. No other API solves this. Doesn't make sense for us to add cruft because we're being standardized at the moment. Don't think it'll benefit anyone, either.
• BJ: can't imagine any UA will hand out English errors for one API and French for another. Raise these properties up to Window or Navigator? Don't want to minimize INTL concerns, but don't understand what this helps achieve.
• KG: think we asked at the wrong time. Think we should not fossilize a partial solution in our V1.
• CW: seems group has no appetite to do this now. We'll go back to INTL group with feedback. Suggest tagging this Polish-Post-V1. We'll deal with it if you tell us what to do. KN can you take on answering this one?
• KN: yes.

(stretch) Passive Fingerprinting Surface #3101

• CW: something we have to talk about one day, but no time today.
• KN: what will we discuss about this?
• KG: I've been drafting something that crystallizes my opinions. Want to clean it up before sharing.
• KG: high level, there are certain un-hidable bits of information, and if we don't diverge from those, it's fine. Can tell the difference between Intel, NVIDIA. Also probably GPU families. Not useful for us to restrict max texture size to prevent fingerprinting, if you can deduce the same from shader math that we can't possibly hide.
• CW: sounds like our general agreement, and is why we were comfortable exposing architecture in the GPUAdapterInfo.

Agenda for next meeting

• Carry over items
• Will ask Intel what they care about
• CW: Tacit resolution queue
• CW: Let's please try to resolve createPipelineAsync offline.
• CW: We have 13 WebPGU V1 issues to discuss. 4 of these are meta-issues, so 9. Getting close - let's keep it up. Can call it done one day.
• CW: next meeting APAC.