Chair: CW

Scribe: KN/JB/CW

Location: Google Meet

• Administrivia
• CTS Update
• copyExternalImageToTexture/importExternalTexture: Add HDR headroom parameter #5236
• Add primitive-index feature and associated builtin #5273
• Should we disallow swizzle with depth textures? #5266
• "Promise Ordering" section should mention device lost promise ordering #5244
• Uniformity Analysis - Account for break if expression uniformity #5277
• Limit the value passed into @align? #5150
• F2F planning
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Alan Baker
  • Brandon Jones
  • Christopher Cameron
  • Corentin Wallez
  • Dan Sinclair
  • Geoff Lang
  • Gregg Tavares
  • James Price
  • Kai Ninomiya
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Teodor Tanasoaia
• Nvidia
  • Anders Leino
• Albin Bernhardsson
• Mehmet Oguz Derin

• CW: Remember to get an ETA for Canada travel.

• CC: Here are some slides as a primer on HDR as related to this issue.
• MW: Proposal looks good but it should default to Infinity otherwise if you need tone mapping you need to specify it every time.
• JB: Defaulting to infinity seems [like it would cause problems]
• CC: if you set headroom=infinity, the image will just get clipped to 1.0. Which means if we make that the default, every application needs to be HDR-aware [in order to not have terrible results when users provide HDR content].
• KN: The concern that made me think we should default to 0 is that the application will fail horribly if the user passes an HDR image and your app hasn't tested with HDR. Don't know that HDR is ubiquitous enough yet to rely on developers testing with HDR. Think 0 makes more sense, even if I imagined Infinity was better earlier.
• RC: Looking at Chris' page, it only goes to 4 and putting it to 4 on my SDR monitor, the colors get washed out. So why allow Infinity?
• CC: 6 is 64 times more brighter than white. Even your eye can't really do that. Infinity is a way to say "whatever the content things is best". Content always has a max headroom and doesn't stretch to higher target headrooms (e.g. Infinity). Because the ISO gain map doesn't specify a max allowed headroom, Infinity seems like a good maximum. But also for PBR games where you deal with "real" light values, you might want Infinity.
• RC: In the stained glass window example, what happens at Infinity?
• KN+CC: It will be the same as 3 because the image specifies that's its max.
• KN: For Image Based Lighting you might want more stops, not Infinity but 6 or something.
• JB: How should importing behave if importing on a non-floating point target.
• CC: Analogous question with color spaces, rec2020 to srgb shaves everything that doesn't fit for example. Having a clear spec that explains where clamping happens is important.
• JB: So if you specify 0 then you ask to pretend that this is a SDR images, or an image displayed on an SDR device. If you specify Infinity to import in a unorm target, then anything above 1 gets clamped.
• CW: Need to make sure the default works the way people are used to seeing when viewing HDR content on SDR devices.
• MW: Primary concern about defaulting to 0 is that if they import HDR and want to use HDR, they don't know what to pass to look correct on the display.
• CC: When you are creating HDR content, you create a scene and decide what you're going to render your seen at. If your display says "hdr" in the media query, you can use two stops of headroom and hope that it will be display well on your device.
• RC: If you read back from an HDR canvas, can you determine what headroom the browser tonemapped to?
• CC: You can never readback the value to find out what it was, because when you read the canvas, [the canvas has the headroom specified on the canvas] and [the target has the headroom specified by the copy operation]. It doesn't use the display headroom.
• CW: No fingerprinting vector, purely numbers [that come from the webpage] crunched into other numbers.
• RC: OK. So tonemapping gets applied only when the canvas is being displayed.
• CW: Have we addressed Mike's concern? Can we get consensus?
• MW: Think we should discuss next week.

• BJ: Primary rationale is that we have vertex_index and instance_index. Most things we call index even though native calls them IDs.
• JB: Mozilla likes _index, and likes the proposal overall
• MW: 👍
• Consensus: Index.
• KN: Are we good to land it after that?
• (all): Yes. (PR already approved by google and apple)

• Prioritization / milestone triage
• Bug triage
• Bindless presentation
• Another whiteboard exercise