Chair: CW

Scribe: KR

Location: Google Meet

• Administrivia
• CTS Update
• (discuss/approve small details of) Add texture-compression-bc-sliced-3d #4763
• [M0] On device loss, should mapAsync throw AbortError instead of OperationError? #4774
• [M0] reuse of an GPUAdapter to request a GPUDevice does not reject. · Issue #4352
• createTexture does not validate viewFormats against usage #4426
• Hardware feature levels (and compat) #4656
• Compatibility Mode: Support OpenGLES devices with zero SSBOs and image uniforms in vertex, fragment stages #4721
• [editorial] Consider if there's a much better name for "image copies" #4573 (comment)
• (Ken) WebGPU benchmark(s) in MotionMark?
• Agenda for next meeting

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

• No meetings next week? (SIGGRAPH)
  • Corentin out week of 8/5
  • Mozilla all hands week of 8/12
  • Next API meeting 8/21
• We should have a WGSL meeting at the next opportunity to talk about shader/pipeline errors (#4711 #4728 #4568) even if it’s the only agenda item
  • Talk about it a bit today?
• F2F two days, Mon Oct 28th + Tue Oct 29th? Tue Oct 29th + Wed Oct 30th
  • KG: Prefer Tue/Wed so people can travel on weekday
  • Probably at Google, 900 Alta Ave, Mountain View
  • CW will send email tomorrow
• KG: Assumption is that M0 is what's blocking for CR. Very few issues to talk about but dozens of "copyediting" ones. If some issues seem like they are not blocking feel free to move them, otherwise lots of good progress.

• Kai: Lots of fixes for WGSL tests. More work on texture load builtins.
• CW: Out of that spreadsheet/burndown chart we shared before, it’s almost 100% with just texture builtins and a few small specific features left.
• CW: Chromium starting an origin trial for some subgroup operations (broadcast etc) and looking to land some tests for that proposal. They will skip themselves when the feature is not available.

• KG: Mozilla suggests changing to bc2d, have another bc3d entry. #5 in the list.
• CW: solutions we don't want? auto-enable we don't.
• KN: between #2 and #3 I'm fine with both. #2 is a little simpler to spec. (No new logic for producing an error.)
• KG: more I think about it, the more I like renaming it to 2D.
• MOD: option #1 is not optimal. I'm OK with the other options.
• KN: don't really want to change the name of the extension. We have bc already, we'd be removing it and adding bc2d. On our impl we'd have to deprecate, do warnings, then remove bc. Bunch of work.
• MM: what's the reason why the other formats could work with 3d but not the other?
• KN: list of format's the same for the 2 features. Just whether they can be used for 3D textures or not.
• MM: why not one extension for 3d, the other one for 2d?
• KN: like ASTC doing it that way? Yes. Wanted symmetry between the compressed texture extensions.
• MM: symmetry's less important than having 2 extensions.
• KN: there'll be 2 for BC and 2 for ASTC. And 1 for ETC since it doesn't support 3D slices.
• GT: ASTC supports 3D 3D, not slices of 3D.
• KN: that exists in some GL impls. Never existed in Vk, D3D12 or Metal. Not even extensions for them.
• KG: not just desire for symmetry; it indicates that they behave differently.
• CW: not sure a rename is super necessary. Option #2 makes sense. One's the format, and the other one's sliced. But it's always predicated on the 2D support. Small opinions one way or the other, so I propose going with #2.
• (consensus)
• MOD: do we carry over the same idea for the ASTC - that it sets texture creation validation error?
• KN: it should work the same way as much as possible.
• KG: agree
• …
• KN: what you have for the table in the current PR is what you want. Just need clarifying text.
• MOD: thanks.

• CW: mostly agreement already
• KN: think we should do this. Technically a breaking change, but device loss is rare.
• KG: agree
• MW: sounds fine
• (consensus)

• (consensus to change adapter reuse to a rejection)
• CW: make things more brittle on purpose?
• KG: Moz's position - better to differentiate "sorry we failed" with adapter loss. "you already created one device". you're actively misusing the API.
• KN: the reason it's this way is we want one error handling path. If it doesn't reject immediately, it never will. However - you're expecting both to happen at the same time (requestAdapter + requestDevice). Failure could be a programming error. But I agree with the logic that this should be a rejection.
• CW: changes spec behavior - gives you an already-lost device? (Yes.) Side-effect is that it removes one of the encouragements for people to handle device loss. Want people to handle this case, though.
• KN: Don't think it's worth the pain of doing this. It's rare and people can reload. Also this should be extremely rare.
• RC: An adapter being lost can mean that it is lost forever, e.g. it was physically unplugged. In the Surface computer there's an Intel GPU in the tablet, and an Nvidia GPU in the keyboard. If you unplug them, the Nvidia GPU doesn't ever come back and adapters should be re-enumerated.
• JB: can also happen when someone undocks. Seems common. Think it's important to do this. wgpu probably isn't doing this right, either. We don't create a new factory on this event.
• KG: FF in browser does support this. Right now, GPUAdapter - once you create a device, you can't use it again.
• CW: the web has easy reload functionality - upon reload, will enumerate adapters again. Probably fine if the page breaks, Ctrl-R to reload?
• KG: we don't want to design APIs to be fragile. Rather, be robust. WebGPU apps don't always save state well enough to smoothly reload.
• MM: which proposal are we discussing?
• CW: we lost one way to encourage developers to handle device loss. Basically, do we need more encouragement in other ways.
• KG: I don't think they're tied together. Have consensus to reject on API misuse. Other thing - we'd reject even if the adapter's lost.
• CW: sounds good.
• MM: APIs like Fetch reject upon network error. For similarity - even if website's correct but something happens in-browser, should still reject.
• KG: that requires people to handle rejection for both requestAdapter and requestDevice. Would like to pretend the adapter's fine.
• CW: because under the as-if rule, the adapter could be lost between the time you request the device, and get it back. Have to handle losing device before you get it.
• MM: returning the device that's lost could be handled in promise rejection. But I won't fight for it.
• KN: there are good reasons we don't do that, but maybe we don't need to discuss them live.

• KG: had the last comment https://github.com/gpuweb/gpuweb/issues/4426#issuecomment-2248617831
• KN: still not clear on why we want to add usages to texture views. Making it explicit that your texture view won't have all the usages? I think error messages are fine for conveying this.
• KG: don't like silent subsetting because it isn't forward compatible. Suddenly it stops working in some situations. Can I use this view, because it was subset or not? At view creation, we can know you're trying to make an sRGB storage binding, and that doesn't work.
• KN: subsetting's an impl detail. Validation that you can't use sRGB with storage is elsewhere in the spec.
• CW: right now, if you want to use storage texture with sRGB, need to declare BGL with texture format sRGB. That fails at BGL creation. Other reason: in WGPU, views in backend are created when the GPUTextureView's created. Nice to know which views to create, and not create all of them. Found same problem in Dawn. We have a conditional somewhere. Right now: this change is almost a no-op. What do you foresee in the future, making this change useful?
• CW: like - ability to declare storage textures without a format, in wgsl? Then not at BGL creation time, but when you bind the texture at BG creation time. Is that the concern?
• KG: need time to look this up on my own. Do we validate usage against format?
• CW: yes, at createTexture time.
• KG: can you make rgba8_unorm with sRGB with storage usage?
• KN/CW: no.
• KG: but you can create a texture view from non-sRGB one if the view format includes sRGB? That lack of symmetry's weird. Gap between validation's weird.
• KN: will always be asymmetric - can't subset the usages at creation time. create sRGB, then make non-sRGB storage view.
• KG: unless we validate … (didn't catch)
• KN: don't think that's implementable.
• KG: sounds implementable to me.
• MM: why is it not?
• KN: Vulkan won't let us create the texture with a format not supportable (?)
• KG: so other format might be supported (?)
• MM: same as 0x0 textures?
• CW: we disallow empty textures.
• KN: I see what you mean KG. It is probably possible but not 100% sure because it's complicated.
• KG: these are the difficulties because we don't want to ask people what kind of view we're supposed to create.
• KN: making it symmetric's a separate thing. Don't need to add usages to views. Could still do it without that.
• CW: should still be possible. Create view with format, we AND the usage of texture with allowed usage of that format. Concern here is it feels like action at a distance.
• KN: think it's more complicated. There's at least one format that supports all the usages, then can create. Will backends always allow us to reverse these?
• CW: we can take this one. Seems more future-proof. Onlybreaking change - storage RGBA8 unorm, view format sRGB, … - we can probably future-proof here. Esp if it defaults to the usage of the texture. In 99% of cases this won't trigger.
• KN: OK.
• KG: resolved?
• CW: I'm OK taking it.
• KN: I'm OK taking it too. The thing in Kelsey's last comment.
• KG: I'll write it up.

• KG would like to move this to M1. (Or, not M0.)
• KN: it is M1.
• CW: Google's side - not for CR - for Compat it's important. In last meeting we got a thumbs-up that Compat can use this mechanism. But the Feature Level mechanism is what Compat would fall under.
• KR: yes that's what we decided last time.
• KN: I'm wondering - we already have 2 feature levels proposed. Core and Compat. Working actively on Compat. You want to see more investigation into higher feature levels?
• KG: yes. Was hoping to see what would shake out of that.
• KN: is there a result of that investigation that would cause us to not do this proposal?
• KG: if we do investigations and find we have multiple different categories of feature levels with different tier numbers, that's different than a single serial list.
• KN: won't be a serial list. Tile local storage won't show up on desktop. Bindless, not on older mobile.
• GT: those are just features. Might not be bundled into a Feature Level.
• KN: they could be.
• KG: could be but don't have to. If only a couple of these things we'd add to Feature Levels, how bad would it be to merge the feature levels?
• KN: this proposal doesn't prevent us from having a single totally ordered list of Feature Levels.
• KG: if we have time to do more investigation into what these FLs would be, better to do that now
• KR: The immediate need is that we need to find how to enable the compat mode. Our preference is to put it in the feature level mechanism.
• JB: risk is - it's difficult to design mechanisms like this in the absence of enough demand to know exactly how it should work. When I look at the convo in Kai's proposal he's doing a lot of extrapolation. Not something engs do well historically. It's the level of extrapolation that makes me nervous. Bad for developers if we design something that doesn't serve future needs. We already have features, would have a third thing, and that's very bad. I think a 3 mechanism story is worse than a bool hanging off the side.
• MM: one potential solution - an enum with different fields for each category of devices. If there's linear progressions, that would be naming conventions in the enum. Query is, does this device support this enum. Later, decide one linear sequence, multiple parallel ones.
• JB: how would automatic downgrading/upgrading work?
• KN: current proposal, the spec'll tell you which upgrades are allowed.
• MM: answer to that question - the group comes up with the answer to that question when they add a new enum value.
• KN: that's how the PR I opened is designed.
• CW: some precedent for desktop vs. mobile feature levels, in Khronos Vulkan. Desktop line of profiles, and an "Android" line. We could see if there are inherent differences and report back to the group.
• MM: think there are 3 lines in Metal. General families ("Common1/2/3"/”Metal3”), “Apple” and “Mac”.
• JB: relationship between Apple and Mac?
• MM: for a particular device, ask it, do you support this particular enum value. Intel values only say yes for Mac enums, Apple Silicon says yes for both.
• CW: my hope is that we can get enough data/precedent for this to be grounded extrapolation. But yes, it's something where we don't want to add a second mechanism for this in the future.

• SW: got internal data from Android team. Percentage of a very large data set. Of devices supporting Compat, devices that could use 0 storage texture/buffers in vertex shaders is 47%. We don't think we should exclude those.
  • MM: denominator in the fraction?
  • SW: supports ES 3.1, supports Vulkan <= 1.0.3, does support FP16/FP32. And these are counting individual devices.
• KG: differentiation on kind of device?
  • SW: didn't do a query on phone / set top box, etc. Gut feeling - phones will dwarf other form factors.
  • KN: I looked at the data - many, many more phones than other types
• SW: Teo suggested my last option - don't introduce new limits, but bring these back as features - storage textures/buffers in vertex shaders - and make the existing limit, applies to compute/fragment but not vertex, and if you have this feature, it applies to vertex shaders too.
  • Other option: 4, or 6, or 2 new limits. Downside - leaves detritus in the core. We think we'd have to add it there. Kai says he has a fix for that - requires another spec change.
• MM: are you proposing changing non-Compat mode?
• SW: if we do the features - doesn't' touch Compat mode. If we add the new limits - those would have to go into Core too.
• CW: if you have a Compat app and want max storage buffers to be 4 - if we don't add the limit to core, it's supposed to reject device configuration. We could say these exist in core but are just a proxy to the storage buffer limit.
• MM: in non-Compat mode, are storage buffers allowed in vertex shaders?
• SW: yes, read-only storage buffers. OpenGL doesn't have the ability to distinguish between read-only and read-write, and since some don't have read-write support, they advertise 0.
• Discussion.
• SW: we want to support this on devices in Compat mode which support the functionality. We also want apps like Maps to have as much reach as possible, and they wouldn't need this feature.
• SW: the thing to think about - are we OK with just having the feature? All 3 values would need to be the same. This would limit compute/fragment SSBOs limits to a lower value.
• …
• CW: Google’s data shows we really need to support devices that don’t have vertex storage. Want to figure out what combination of features/limits is palatable.
  • KG: Want to know what % of reach of compatibility mode vs all devices.
  • CW: Compat is about 50% of android devices.
  • KN: And this question is roughly 50% of that.
• KG: Gets back to Myles’s concern that compat is the “new baseline” of webgpu.
• CW: A new feature level, that not everyone has to implement.
• CW: Please continue discussion on the issue.

• (skipping a few weeks due to siggraph and absences)
• Agenda
  • [M0] reuse of an GPUAdapter to request a GPUDevice does not reject. · Issue #4352
  • createTexture does not validate viewFormats against usage #4426
  • Hardware feature levels (and compat) #4656
  • Compatibility Mode: Support OpenGLES devices with zero SSBOs and image uniforms in vertex, fragment stages #4721
  • [editorial] Consider if there's a much better name for "image copies" #4573 (comment)
  • (Ken) WebGPU benchmark(s) in MotionMark?
  • Add items to the F2F agenda!