Chair: CW

Scribe: KR

Location: Google Meet

• Administrivia
• CTS Update
• F2F scheduling
• Compat: Limits added for compat need to behave in a forward compatible way #5013
• Compat: maxStorage(Buffers/Textures)In(Vertex/Fragment)Stage should be more like maxStorage(Buffers/Textures)PerShaderStage? #5033
• Allow using a texture view for an externalTexture binding #5079
• Move isFallbackAdapter into GPUAdapterInfo #4971
• Triage the rest milestone 1 issues
• (stretch) minutiae: What happens to GPUColors outside the range of f32? #5020
• Agenda for next meeting

• Google
  • Brandon Jones
  • Corentin Wallez
  • Geoff Lang
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
• LunarG
  • David Desormeaux
  • Mark Young
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Nvidia
  • Anders Leino
• Albin Bernhardsson
• Mehmet Oguz Derin

• F2F scheduling
  • CW: Do we have plans to schedule a F2F? Not yet, but let’s start talking about it. It seems like H2 should be fine
  • (silence)
  • CW: that should give enough time for travel budget, hotels.
  • CW: North America is a good choice, most people on the call are there, Canada would be nice. Google could host in Montreal if need be, or possibly Waterloo. Perhaps September or October 2025, avoid conflicts with TPAC, etc.
  • KN: Khronos F2F are Week of May 12 (Seoul), and week of Sept 21 (Philadelphia)
  • KR: Might have jury duty 2nd week of October, might be 5 weeks . September would be best for me.
  • Corentin likes the weather in Canada in September
• GDC WebGL+WebGPU Meetup the evening of March 19
  • https://www.khronos.org/events/3d-on-the-web-2025
  • If you're coming to GDC, please consider coming and co-presenting! Please email Ken.

• GT: Big refactor to normally enable all features but then skip missing features. The way things are now, new features don’t get turned on, and tests that were supposed to cover them don’t. Also seems to be a simplification. Seems like about 60-65% done.

• CW: SW is out sick
• CW: he filed TAG review: https://github.com/w3ctag/design-reviews/issues/1063 . Hopefully on the path to shipment now!
• Only 2 issues left that need discussion.
• This one #5013: it's done!

• GT: done too!

• CW: PR version of what we discussed. Any comments?
• KG: concern - introducing a lot of formats that didn't previously have to be handled by external textures. If any polyfills for e.g. depth or stencil textures, will have to handle those in external texture binding code, too. Less risky if we restricted it to certain formats.
• CW: load-bearing validation here - the format must be filterable in the color format table.
• KN: with float32-filterable enabled, that's exactly all of the unorm/snorm/float [and srgb] formats
• KG: any polyfills for those formats? Any caveats?
• CW: not that I'm aware of. The only one - BGRA and/or complexity with sRGB. Not that we inject a binding that'll inject a uniform that gates swizzling. Think it's fine.
• KG: good idea for impls to check there isn't a conflict here.
• CW: we have homework for our various implementations.
• JB: the rest of the PR seemed fine.

• JB: we shouldn't put useful information on the adapter that you can't obtain from the device.
• CW: that'll be a breaking change then.
• JB: we can duplicate it. It's read-only, but it's our fault.
• BJ: just historical cruft. Didn't have AdapterInfo when we introduced fallback adapters.
• CW: so we just duplicate it?
• GT: since Chrome's just shipped and since we don't ship the fallback adapter right now, the feature's unused, though the flag does exist.
• CW: you'll get "undefined" rather than false.
• KR: undefined coerces to false. :)
• BJ: it'd be hard for someone to notice the difference.
• CW: if everyone's OK, we can move it in the spec, and Chrome will try to move it without breaking websites. If we break too many then we'll come back to the WG.

• Got through a lot. About 10 left.

• KN: GPUColor has four doubles in it. Can represent f32, i32, u32, and then we cast them in the impl. SetBlendConstant always uses it as f32. There are some steps defining how the conversion happens to the right type. Not ironed out yet. ClearValue, when casting large f64 to f32, can give infinity. Then go through WGSL to convert; results in indeterminate value. Should we say that we convert to float_max so it's better defined? If we have unrestricted floats and want to clear an attachment to infinity when we have unrestricted floats, you should be able to do that, but maybe we want a way to do that?
• KN: SetBlendConstant doesn't say how the conversion happens, but it will run into indeterminate values at some point.
• BJ: do we need to consider depth clear values too?
• KN: depth clear values are f32 in the spec. We receive them as that, then have to convert to normalized value, but that's well defined.
• KN: not sure there are decisions to be made here. Maybe make the clamping from float64->float32 well defined.
• KR: is this clamping done in JS or WGSL?
• KN: JS.
• BJ: does C header take f32?
• KN: f64 so it can represent multiple types.
• CW: just defining how we convert f64 to f32 then.
• KR: concerned about incompatibility between CPUs and JS engines in rounding behavior.
• KN: Web IDL is very strict and we already rely on its rounding / conversion behavior.

• Agenda requests
  • Make the last 2 arguments to copyBufferToBuffer optional #4807
  • Improve source size calculation used by copyExternalImageToTexture with HTMLImageElement #5097