Chair: CW

Scribe: KR

Location: Google Meet

• Administrivia
• CTS Update
• [M0] Alpha to Coverage spec and conformance on Qualcomm hardware #4867
• [M0?] Guarantees about early-z fragment discard #4878
• [M0] Canvas contents after device destroy or device loss #4859
• [M0] empty array entries in createPipelineLayout and other place should/should not be ignored? #4879
• [M1] Feature detection for HDR canvas #4828
• [M1] Allow only strings in featureLevel #4874
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
  • Myles C. Maxfield
• Google
  • Brandon Jones
  • Corentin Wallez
  • Geoff Lang
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Stephen White
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Nvidia
  • Anders Leino
• Mehmet Oguz Derin

• Please take a look at the PR refreshing the charter!
• F2F agenda items, please take a look and add your items

• Texture builtin tests still ongoing
  • textureGather driver bugs are still there :)

• RC: driving to 100% conformance on Qualcomm on Windows. This one isn't possible on Qualcomm hardware because of how they do alpha-to-coverage. The behavior is allowed in D3D, but if the conformance test reflects WebGPU then it can't be passed.
• JB: Moz thinks that if the test was intended to be overly strict, it's served its purpose as the canary in the coal mine. Amending the spec to reflect what's going on is fine with us.
• CW: might want to make a note in the spec saying that alpha-to-coverage effects aren't local to the pixel.
• KN: editors will take Rafael's spec text and integrate it.
• Resolved

• BJ: was brought up on the WebGL dev list, paradoxically. Writing to a storage buffer in fragment shader, relying on early-Z discard. On Vulkan, if you write to storage buffer in fragment shader, starts skipping early-Z discards, similar to writing FragDepth. This is the behavior in Vulkan. Where's the confirmed behavior in D3D and Metal specs? Appreciate pointers on the issue. The WebGPU spec doesn't say anything about this. If this happens all the time, we should probably mention something. If we need to force this, can have the shader start emitting frag depth writes when they have storage buffer writes, to normalize the behavior. But I assume all the APIs are probably behaving similarly.
• JB: Are underlying platforms giving a way to toggle early-Z
• MW: Metal does: [[early_fragment_tests]]! Would need to check more to see what the consequences are.
• GT: We should add a test! Similar to the test for per-sample shading (affected by sample index, interpolation qualifiers) and writing to a storage buffer. There were behavioral differences on Metal.
• RC: Direct3D 11.3 Functional Specification (microsoft.github.io) section 16.9.3 talks about early-Z.
• KG: AFAIK this early-Z is an optimization, and gets into observability, so it shouldn't be observable if it happens. The goal of the optimization it to be non-observable. If there are side-effects, the optimization shouldn't be happening.
• BJ: generally agree. This is Vulkan's approach. Vk has an extension (not sure how widely supported), lets you opt in to having the side effect. Anything that would make that side-effect observable disables the optimization. I assume it's true for the other APIs too.
• MM: So the proposal is that if there's side effect, then you cannot do early-Z discard.
• BJ: not really making a proposal, but saying this is the observed behavior of the API. Make it uniform everywhere? Force it to be uniform? Either way, think we should document the behavior.
• MM: the way you'd observe this, do a side-effect in the fragment shader, see if multiple overlapping triangles cause repeated execution of the fragment shader.
• KN: can test 2 things. 1) writing to storage buffer disables early-Z. 2) whether it's unobservable if you do early-Z discard. (2) is not observable except by performance test and I don't think we should try to test it.
• CW: want to check on the various APIs. If there are side-effects want to make sure early-Z discard doesn't happen.
• KG: do we have spec text?
• BJ: have some, wrote 1-2 weeks ago. Talks about FragDepth builtin, whether you can do early-Z discard. Would add a line there if all of the underlying APIs agree.

• KN: last meeting we discussed this, said it'd be good if we had the canvas revert to the previous frame if the device is lost during a frame. Number of ways this can interact with looking at the canvas's contents as an image source (draw to 2D canvas, upload to WebGL). Wrote up 4 options. See the PR.
• 0. Don't do the reverting thing we talked about last time.
• 1. First doesn't work. Requires an actual copy.
• 2. Requires us to do stuff inconsistent with how HTML spec is written.
• 3. Doesn't have these problems but does allow drawImage to see the contents reverting. In-progress with a live device, vs. the device being lost. Think it's fine, but not a trivial choice.
• GT: are we talking about destruction or loss?
• KG / KN: both, but you didn't lose the GPU process, so you still have the texture.
• KG: more limited than loss, but trying to describe both with the same language.
• CW: we spec what device.destroy() should do, but we want this to be the same as best-effort device loss handling.
• GT: I'd say we're only defining destroyed, ignoring whether the user or the browser destroys it.
• KG: useful example of device loss - you have old contexts the browser decides to freeze or close to reduce memory pressure, like on an old tab.
• GT: right, but the browser actually destroys the context in this case.
• KG: w.r.t. the spec, that's device loss.
• CW: why is option (1) a no-go? Why does it require a copy?
• KN: in that one, when we need the contents of the canvas we commit whatever you're currently working on to the canvas. Those will be the next canvas contents. If you use drawImage in the middle of a frame, you need to see those rendering results. Need to preserve the drawing buffer. Can't move it to the front, because we might keep drawing. drawImage might happen in the middle of a frame.
• KG: sound weird, but having drawImage based on current contents but compositor displaying the last committed frame conceptually makes sense.
• CW: you're saying option 3 makes sense.
• KG: yes.
• CW: is option 1 tractable with the copies? User tries to do drawImage during a rAF. Make a copy? Seems it might happen often.
• KN: based on what Kelsey said, might be something between (3) and (1). You drawImage, so you captured it, we'll commit it, put it on the display even if you lose the device afterward.
• KG: calling drawImage from a WebGPU canvas doesn't mean that's the thing you want to show up on the page. Only guaranteed way to know this is for you to leave it that way and it presents it to the screen.
• CW: makes sense, but think some people might be tripped up by that. Seems no solution that's intuitive to developers in all cases and also easy to implement by browsers.
• RC: talked about this being best-effort. Is it OK for the browser to be an under-achiever? #0, in the case where you share one context across WebGPU, canvases, etc.?
• GT: do feel there's usefulness in talking about 3 cases rather than 2. Not just destroyed and lost. Lost that the browser destroyed, lost that the user destroyed. Other thing - don't understand #3 from the user's POV. Draw B and let it get to the screen. Draw A, call drawImage, destroy, call drawImage (missed some of this) - you'll get A in first drawImage and B in second.
• KG: caution against having an M0 issue that we want fixed right now, and issues depending on it in M0. WebGL doesn't spec this that well. Don't think this is a release criterion for our spec.
• KN: would like the normal-case behavior to be well spec'd, because we have destroy(). But wasn't going to spec what happens if GPU process crashes, or GPU is unplugged.
• (agreement)
• CW: on Gregg's case - draw B, then draw A, getImage, destroy, getImage. One getImage gets A, the other B. You resort to grabbing the front buffer. Pretty surprising. Sort of a corner case. Way to handle this - getImage takes a snapshot for the use of getImage. At end of rAF, if device is alive, put back buffer in front buffer, but getImage has its own special snapshot buffer.
• KN: think this is option #2.
• KR: What had so many issues in WebGL backbuffer management in Chromium, the user destroy the device, let's simplify things and give them a blank image. Thinking about how this logic was in WebGL was extremely hard, worry about the complexity in WebGPU.
• KG: The spec for device loss will be a SHOULD instead of a MUST so that's allowed behavior.
• KN: We still have to spec how images are handled. I'm OK with option #0.
• KG: I'm advocating for latitude in UAs implementing this. How much do we think it should be required that the canvas is cleared? If we don't think it MUST be cleared then we can leave it to the UA.
• KN: we're then allowing UAs to have 1 of 2 behaviors and we need to test them. We have existing tests, have to update them.
• KG: cautioning against spec'ing something because we should. Downside of not testing this is low. "Should" we be nice?
• KR: advocating again for the simplest solution. Perry Wang from Tencent just contributed a fix to WebGL's back buffer to correctly clear it, and this caused a regression bug to be filed.
  • Regression: Gaming Extension page getting blanked after open and close sidepanel
  • Resizing WebGL canvas does not always reset its displayed image
• CW: Option 3 seems implementable at least in Chromium.
• KN: Think so too, not that different from what we implement now.
• KN: I'd do what Kelsey proposes for M0 (allow either clearing or preserving the canvas) and keep a bug open for M1.
• CW: that works.
• Resolved

• Chromium regression. Closed.

• KN: came up on WebGPU Samples - have an HDR sample now. ccameron suggests reflecting what the canvas configuration is, so you know whether your tone mapping request was honored. (Paid attention to by the browser, and obeyed.) How does feature detection work for hardware support? Know if the browser's looking at the option, or not.
• MW: thumbs up
• KG: there's a way to know if the browser consumed the request. Add a get observer to the dictionary, find out whether the browser actually accessed it. You still don't know whether the browser used it. Was recommended by HTML spec authors for WebGL-related dictionaries. Could do something similar here.
• KN: messy but can be done. Would you prefer to rely on that rather than reflecting the configuration?
• KG: I like reflection.
• KN: sounds like everyone's happy with that.
• KG/KN: testufo also asked for a query about “whether HDR support is GPU-accelerated or not”, not totally clear what this would mean
• Resolved - reflect the information.

• JB: Mike and I approved.
• CW: Don't need to talk much about it.

• No scheduled WGSL meeting next week
• Canceling next week. We're out of agenda items for now!
• Please add F2F agenda items! See Administrivia section above for the link.