Chair: CW

Scribe: JB/KN

Location: Google Meet

• Administrivia
• CTS Update
• Support for gl_PrimitiveID / SV_PrimitiveID -like construct? #1786
• Support Resolve for 16unorm and 16snorm in texture-formats-tier1 #5237
• copyExternalImageToTexture/importExternalTexture: Add HDR headroom parameter #5236
• "Promise Ordering" section should mention device lost promise ordering #5244
• Unrestricted Depth Range #5209
• GPUBindGroupLayoutEntry is accepting an empty dictionary for externalTexture, should accept boolean instead #5249
• Agenda for next meeting

• Google
  • Brandon Jones
  • Corentin Wallez
  • Geoff Lang
  • Gregg Tavares
  • Kai Ninomiya
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
• Mehmet Oguz Derin

Please fill

• CW: This is present in all APIs but sometimes gated on versions / extensions. Useful to get per-triangle data (normals) or when rendering the triangle ID for Nanite-like usecases.
• JB: Surprised that this didn't exist already because it seems so useful to reduce memory consumption.
• CW: Agreement for "PR welcome"
• JB: Optional feature to expose where it's supported?
• CW: Yes
• KN: What is needed in Vulkan for this?
• CW: Geometry, tesselation or RT, most devices.

• CW: More capabilities we found we might be able to add while implementing this in Dawn. Found others to consider, but this is probably the only one we'll propose.
• Teo on bug: "unless we are ok with the feature not being available for Mac1, Samsung Xclipse 920 and a lot of Mali devices"
• CW: Are we okay losing the texture-formats-tier1 extension on Mac1 if we enhance it like this? For Chromium it doesn't matter as we should no longer on these devices soon but could matter for Firefox?
• JB: Not sure, would need to see how many users will lose support for that extension. Not sure we have the data. Not a strong enough opinion.
• CW: If it’s not a clear “yes”, then we should probably drop this proposal. We can always add a new extension later. But it’s hard to make a subset extension. So it’s best to be conservative if it’s not an obvious win.
• JB: leaving things as they are is fine with Mozilla
• Consensus: Not do that.

• KN: It would be nice to have some way to interoperate with HDR images and videos, and get their data into WebGPU. There is currently no spec for this. Canvas2D and WebGL already have this problem: the entry points that let you copy in video assume SDR. This proposal would add a parameter that lets you just specify what your headroom is. Headroom is “how much higher than SDR can you go?” You can specify what headroom to tonemap the SDR data to before it’s handed to WebGPU. The default would be no conversion. That does get converted into extended sRGB, so the representation would be where 1.0 is SDR white.
• BJ: Is there anything in the browser that would tell me what the headroom of my display is?
• KN: We’re working on adding that, but it may not be available in all browsers, including Safari (for fingerprinting). Typically what you would do, without knowing the headroom, is simply pick a headroom to do your work in, and then display your canvas with the same configuration, so that the tonemapping happens on final output.
• BJ: So you can set the headroom for the canvas as well?
• KN: No, but you can set whether it’s HDR or not. There is a proposal out there for limiting the headroom to a specific value, and to control things for galleries of assorted images, but that’s a separate proposal
• BJ: My concern is that there are not pretty clear guidelines of where this data is supposed to come from. So there’s a risk that a high-profile example is just going to set a value of “3”, say, and then the entire web will copy that, and the knob has become useless.
• KN: The closer you are to SDR, the closer you are to targeting common hardware. So a fixed value of 3, say, might not be that bad, if it’s a value people really use.
• GG: What does tonemapping really mean? What happens to stuff above the max headroom?
• KN: I believe there is a specific algorithm being proposed, that preserves all values up to SDR, and then a roll-off for values above 1.0.
• CW: Reading Mike’s question: Is the default of 0 suggested okay? Seems like a breaking change. Infinity would be the current behavior.
• KN: I think that’s not correct. The specs are all written as if HDR doesn’t exist, so there’s no way to get data over 1.0 at all. So nobody is implementing the behavior as infinity right now. I think in practice everyone is clamping to 1.0.
• BJ: If I set the headroom to 1.0, is that the same as SDR, or is 0?
• KN: I think 0 is SDR, 1 is 2xSDR.
• JB: You’re supplying the exponent, so a value of 0 gets you current behavior.
• CW: looking at copyExternalImageToTexture, that does color encoding, and that says that values are not lost to clamps.
• KN: Oh. Well, then maybe we are handling data over 1.0 after all. I had forgotten we had that in there.
• CW: Jim/Mozilla?
• JB: Need time.
• CW: Okay, so: we need to investigate what browsers are doing right now, to make sure that the default doesn’t change current behavior. If browsers are behaving inconsistently, then we’ll need to figure something out.

• KN: I probably didn’t write anything down about this because there are no guarantees about when device loss happens in the first place. Even if you call destroy you’re still racing with other async stuff.
• KN: For onsubmittedworkdone and mapasync, we can’t tell whether the destroy operation will complete before the actual work, so we don’t know. Teo linked to some async pipeline tests, I haven't looked at these. If they are assuming that async pipeline creation will take longer than destroy, I don't think that's valid, and we need to fix the tests.
• JB: When Firefox implemented call buffering, batching up sequences of JS API calls to transmit over IPC, we also ended up batching the promise resolution, and get back a list of promises to resolve. That's probably why Teo was looking at this, had to choose an order. If it turns out we don't want to specify it, then that's an easy requirement for our implementation, but the spec should have a note if it's not ordered.
• CW: I think it’s correct that we can’t specify an order, because there are two things racing to complete on the device timeline: figuring out that the queue / compilation has finished, and on the other hand the “lose the device” algorithm triggered by destroy. Since they’re racing on the device timeline, the spec can’t require an ordering.
• CW: Can we call this editorial?
• JB: I think so.
• RESOLVED: Editorial: make it clear that there are no guarantees here

• CW: It seems like we need more investigation here
• KN: We’ve been talking about this for years, so I just wanted to get an issue filed for it. It seems like it’s only available on Vulkan
• CW: We should investigate D3D and Metal. Probably premature to talk about this today.
• KN: There’s a note on the issue this came from that setting a value outside 1.0 is a validation error on Metal, so maybe Metal doesn’t support this at all.
• More investigation needed.

• CW: Someone has suggested that we should allow a boolean in the dictionary for externaltexture bindings, claiming that in other places on the web platform you pass a boolean, rather than an empty texture
• JB: This issue came up when implementing ExternalTexture in Firefox. DOM folks were surprised by that IDL shape. I explained this was more of a Rust enum so don't know that we need to take this suggestion.
• BJ: Assuming that the only issue is because the externalTexture case has an empty dictionary.
• JB: Correct, the WebIDL didn't make it clear this was a mutually exclusive case, and the spec forgot to validate actually.
• KN: We did this because we wanted a place to add future extensions, but also for consistency. Should add a comment in the WebIDL. We could support "true" in 3 other cases that have defaults that are valid but don't think we should do it.
• JB: Agreed.
• Consensus: Resolve without changes.
• KN: There seem to be a few other cases on the Web platform where the API accepts a dictionary or a boolean
• CW: Those cases seem to all be stories where we started out as just a “yes/no” boolean, and then later decided that we wanted to be able to provide more details, and added the dictionary as a “true, and…” possibility. This doesn’t make the case that a boolean is a desirable approach

• CW: Let's skip at least next week.