Chair: CW/KG

Scribe: MM/CW

Location: Google Meet

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• (timebox) Push constant proposal #4612
• Should copyExternalImageToTexture allow a slice of a 3d texture as a destination? #4697
• bgra8unorm storage textures without bgra8unorm-storage, should generate WGSL error? #4711
• writing to storage buffers/textures in fragment shaders with multisample targets is not portable. #4696
• mapAsync early-reject doesn't generate a validation error #4690
• maxInterStageShaderComponents seems to overlap with maxInterStageShaderVariables #4688
• Allow all vertex input attributes to be considered OOB if at least one is (in the "process vertices" algorithm) #4668
• 3D compressed textures: ETC on macOS is failing validation #3183
  • (Relevant) ASTC Compressed for Sliced 3D as Extension #4701
  • Consider moving sliced 3D compressed BC texture to an extension. #4705
• (stretch) Hardware feature levels (and compat) #4656
• Agenda for next meeting

• Google
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
• Microsoft
  • Rafael Cintron
• Mozilla
  • Kelsey Gilbert
• Nvidia
  • Anders Leino
• Mehmet Oguz Derin
• Myles Maxfield

• CW: Nothing
• KG: One idea in the WGSL idea: Make a CR label to mark such issues needed for CR. I was going to do it.
• BJ: Much appreciated
• KN: I was thinking we could put them in M0 but that doesn’t make sense right now. There are things in there which aren’t relevant
• KG: We could use M0/M1
• CW: We could
• KN: For anything not importing in M0 we could move it to M1, and then use the remainder in M0
• KG: That’s good
• CW: Yep
• KN: Let’s clear out the stuff from M0.

• KN: I’m working on having tests destroy all of their resources, instead of just some of them, so things behave well. Did query sets, will do buffers and textures. Should improve reliability of the tests. Beyond that, IDR what’s going on. Some compat testing, some WGSL sampling & texture store tests. Alan did it for OOB rules. Also, there are some bug fixes for tests trying to create pipelines with no attachments. Apparently Dawn allows that? Dawn is wrong, and I don’t understand how.
• CW: I thought we had validation for that
• KN: Yes, me too. Jasper bumped the issue for lifting that restriction, which would require API surface for describing the size of the render pass
• GT: I just tested it and I got the error message
• KN: We have to look into it
• GT: I just modified a lot of tests to use the new interpolate param. Several hundred tests require that, so expect many tests to fail until you support the new syntax.
  • Compat: Refactor tests to use @interpolate(flat, either) #3814

• Clarify that create*PipelineAsync must not generate a validation error #4714
  • CW: Coming from WGPU contributor. Spec seems to say “validation error should be produced” but the test requires none to be. I have a vague memory the spec is wrong, but not sure
  • KN: I think so too, but the implementation is complicated. createPipelineAsync() wont’ know validation results until it’s done, and would then go back in time to insert the error into the sequence at the correct place. Also it’s a pain to actually use, which I commented about on a different issue. If you want to catch both errors, you have to write your JS in a gross way.
  • CW: We can ping MikeW directly (he’s not here). Would there be concern at Mozilla?
  • KG: This ties into mapAsync doesn’t generate a validation error. The spec says it should be produced… <missed> These aren’t the same issue, but the 2 issues inform each other.
  • CW: Should we take this out of tacit resolution?
  • <all>: yes
• Add missing multisample.count validation #4681
  • CW: It has to be 1 or 4.
  • KN: We required it on texture creation, but not on render pipeline creation.
  • KG: We agreed to this already.
• Define level of detail #4694
  • CN: BJ has a PR to add a normative reference to the Vulkan spec
  • KN: Is normatively referencing Vulkan cool with people?
  • KG: It might not be OK with MikeW
  • <all>: Let’s ask MikeW
• Uncapturederror and preventDefault #4708
  • CW: What happens? The spec should say normatively that the UA should not print things to the console if preventDefault is called on the event. But it’s a normative “should”
  • GT: This is what Javascript does
  • KG: Seems reasonable.
  • KG: Why is this tacit resolution?
  • CW: It’s not in our layer
  • KN: It’s non-normative
  • KG: That doesn’t match what I would expect. But it’s OK I think
  • CW: “Tacit resolution” means “anything that anyone doesn’t think is tacit resolution then it isn’t”
  • KG: This is on us because we didn’t discuss it ahead of time, because it was in tacit resolution queue?
  • CW: Do you want me to write out the list of issues in the email ahead of time?
  • KG: Well then they’re just issues. Tacit resolution is most useful for PRs for things we previously agreed to
  • CW: Should we stop doing tacit resolution?
  • KN: We may not need it
  • KG: We don’t do it in WGSL
  • KN: We used to need it mostly for bug fixes that weren’t technically editorial, but the spec didn’t say what we thought it did
  • CW: I’ll remove it from future agendas.
  • CW: This one, we remove tacit resolution queue, and ask for folks to agree and get consensus on the issue (it should be simple)
  • KG: I’ll ping JB but I’m pretty sure it’s fine.
• Add extended range #4500
  • CW: I’m sorry I keep pinging you on this, KG
  • KG: I was going to get to it, and was going to do it last night, but then I saw it wasn’t on the agenda so I didn’t
  • KG: I’ll finish it after this. It’s a little frustrating to deal with renames retriggering the review process for me
  • KN: It wasn’t just the rename, it was also loosening the spec slightly
  • KG: In the future it would help if we landed more things speculatively. This could be in the spec already, and we could be fixing it
  • CW: It will be nice when we’re post CR because we can take snapshots and we can look at diffs. Right now, Intel has been working on dual source blending, and has had a month and a half of overhead asking for reviews of stuff.

• CW: Can we discuss this without MikeW? Probably. He seemed to agree.
• KG: We didn’t get a chance to talk about this on our team. We agree that it’s at least M2, and we wanted to prioritize the other issues, and there are a lot of other issues. Let’s not talk about this.
• CW: Sounds fine. WGPU has it, MikeW agreed… it’s clear it will happen at some point. People can start experimenting, even if it’s not 100%. There will be output on the agenda request for a Pacific time meeting, then.

• CW: This is an oversight.
• KG: If implementations can do it, then yes
• CW: It wasn’t there because of renderability. But now, renderability to slices is guaranteed.
• KN: If people are thumbs-up on the general idea, we can try to implement it and make sure.
• CW: Let’s try to implement and make a PR.

• CW: Which kind of error should we use? Compat mode uses WGSL error
• KG: Having the feature disabled on the device should make the device behave very similarly to what would happen if the implementation had no idea that this would be spec’ed. In a world where you have an implementation that this is possible, is this an error at shader compilation time? If it is, then if you do know what it is but you just disable it, it should be that way too.
• KN: Yes.
• CW: We should take this, then
• KN: It’s not just compat, too
• GT: It’s a breaking change
• CW: An incredibly minor one. It’s a spec bug.
• GT: Okay. I would also like to see consistency. It’s possible that Unity already has their stuff and expects us to pass. It used to be that you could have a shader module with 2 entry points and you could pick at runtime which one to use. But now it will be an error. We could check if they break
• KG: If it never worked in multiple implementations, it’s not much of a backwards compatibility issue from the perspective of standardization
• CW: We can check with Unity
• KN: (pretty sure) this is the only place where we allowed you to write it into the shader and then not use it, I think it will not be a problem. I would be a little surprised if Unity would rely on it. Most applications generate their shader based on what they end up needing.

• CW: The spec doesn’t define it, and implementations are not consistent with their sample rate. You might end up with 4 or 1 for a given texel/pixel.
• GT: I’m just pointing it out. I don’t know if we want to point it out in the spec, or somehow disallow storage textures when multisampling is on? Or just add a note saying “don’t use this”
• KN: If we were able to for the sample index to be used (compiler wouldn’t omit it) then we would get consistency for M1
• GW: Yes
• KN: I’m surprised that M1 … It seems like you’re writing to a storage buffer, so we better do it once-per-sample… I’m surprised they would choose to do 4x as much work as they need. It could be a bug?
• KG: In some ways, that’s what I expect. If you think about it the way it’s written, the as-if behavior is that it always runs 4 times. When it always run once, that’s an optimization “i can coalesce”. In this case, Apple is the only one doing it correctly and saying “i cannot coalesce these”
• KG: None of the other APIs attempt to hide that.
• GT: If you’re using a sample buffer or sample texture, then the backends can inject the use of sample index
• KG: as a work around
• CW: We could say “if you have side effects, you get sample-rate shading”
• KG: Well you’d say “you get sample rate shading anyway, and it’s not observable if you don’t get it”
• CW: Sample rate shading is not the behavior as-if, because a single computed sample
• MM: Sample rate shading spawns more threads. Not about writing to more spots in the resource
• KG: I’m worried we’re confusing a colloquial use of “sample rate shading” with the term-of-art
• CW: We could say in the spec “if you have side-effects, there is 1 invocation running per sample covered”, and it’s consistent across all backends and implementations.
• KG: Yes. That matches what I’m hoping for
• CW: We’ll ask MikeW too. How about you, GT?
• GT: Yep
• KN: How difficult is it to force a use of sampleindex? It often gets optimized out. How did you force it to be used, GT?
• GT: I assigned it to _. Also I assigned it to the output of the fragment shader
• KG: If we do it today and land the tests, and things continue to be like WebGL, and use our CTS as their criteria for release, then we’re fine. This is the class of workaround you usually want to have
• KN: We could go the other direction, and push implementations to do the other thing consistently. We wouldn’t force sampleIndex if you have side effects, and instead we would force only a single thread to be run if there are side-effects. However, if your shader uses sample index, we’ll still have to force usage of it, because some drivers will optimize it out and affect semantics, which is a no-go.
• CW: There always constants which are injected by the implementation which we know to be / or not be 0 but the compiler doesn’t
• KG: It sounds like there’s a strong desire to force multiple threads to run on all backends.

• • Clarify that create*PipelineAsync must not generate a validation error #4714
• CW: This was from Teo?
• KN: I don’t remember what caused me to file this
• KN: Right now, mapAsync generates a validation error and rejects, except in one case where it only rejects. createPipelineAsync is unclear in the spec but we have tests which make sure it doesn’t generate a validation error.
• KN: mapAsync should be consistent with itself: It should always do both or always do one. We decided a long time ago to do both but I think we could change it to only reject.
• MM: I think mapAsync should do both, because of Javascript ergonomics
• KG: KN expressed implementation concerns…
• KN: For mapAsync it isn’t, but for createPipeline it is. For mapAsync, all validation happens immediately, but that isn’t true for createPipeline
• KG: What about OOM errors? Those are always possible to generate from
  • KN: “out-of-memory” only allowed in a few places. OOMs from unexpected places are supposed to lose the device.
  • MM: Think that’s user hostile
• KG: What places? As an existence proof, as a place where it has to be implementable, that exists, right? The idea that it’s possible to keep an error scope that was pending for a while, is like, has prior art in our spec. In light of that similarity, is it still very onerous?
• KN: I don’t recall if we have any other cases where an error scope would need to be held open like this.
• KG: To me, this is the purpose of the error scopes
• KN: In principle it’s implementable. But <missed>
• KN: The ergonomics, if you actually want to catch both error… the last comment on #4690… it’s ugly.
• MM: does pop error scope provide information that a promise rejection can’t provide?
• KN: The advantage of promises is that you can associate data with the rejection whereas a popErrorScope just gets a string.
• KG: One reason to have both is that we want to support the reject behavior, the reason to have an error scope is that we could also want to catch in a larger error scope for the whole frame.
• CW: Is early-reject an error?
• KG: Is failure to compile an error? Maybe. You might choose to try to compile something without knowing whether or not it will compile. Then failure to compile is not an error. It’s really only an error if you expect it to succeed.
• CW: Rejection here is definitely an error
• KN: I updated the code snippet to use an “internal”-type error scope, because that’s the way you’d actually do this.
• KG: We need to think more about whether these things should be errors or not
• KN: Whether the rejection should be error scope errors?
• KG: Yes. And whether the two should be consistent.

• KN: MikeW filed this. Yeeessss…
• KN: This came to be because we thought they were different and then we had to update the validation for “Components so every output used 4 regardless of how big it was, and then they became very similar. They have different accounting, though, so they’re not the same. I have no idea what we should do.
• KG: What is the difference in accounting?
• KN: Some builtins are counted toward one but not the other. I think that’s the only difference.
• KG: The answer is probably “they are subtly different”
• CW: If we were to make WebGPU today, we’d try very hard to make a single one, because we’d know what we didn’t know about the Vulkan spec previously
• KN: If I wanted to fix this now, I’d pessimize the accounting so they both measure the same thing, and keep both limits, but say if you raise one it also raises the other one. It’s kind of janky, but it would simplify how things work. Some programs will become invalid though
• MM: Unclear how many
• MM: What’s the WebGL story? It has builtins and limits and shader stage components
• CW: I think we should add a note in the spec that says “yeeeeaahhhh, we know”
• KG: “They’re very similar but not the same” is probably the solution here
• CW: We should probably say implementations must have one be a multiple of the other
• KG: Yeah…

• KG: Sounds good.
• CW: Sounds good on our side as well.
• CW: We’ll ask MikeW for concerns
• KN: I think the spec already allows this, and it sounds like what we actually want to do is tweak the way it’s written in the spec.
• KG: We can do the tweak!

• CW: Where were we on this?
• KG: We discovered that ASTC only supports 2D textures guaranteed and 3D is optional
• CW: Same thing for ETC, right?
• KG: I don’t know.
• KG: ETC2 textures don’t support 3D textures … to some degree. In GLES3 you can use ETC2 textures with 2D arrays, which are 3D arrays with 2D array views in our spec.
• CW: The vulkan spec only guarantees (2D BC && sliced-3D BC) || (2D ASTC) || (2D ETC2)
• CW: WebGPU says 3D only works with BC, and
• MM: I don’t think the WebGPU group will invent new technology… We should just take the common subset of functionality among all backend APIs and add validation for that.
• KG: <missed>
• KG: We need to be clear what we mean when we say “textures”. As written, this is a regression from OpenGL and WebGL. They work for 3D textures from a 2D array in OpenGL.
  • 2D arrays vs 3D vs 2D slices of a 3D
  • It’s possible there really is a regression here in Vulkan.
  • When we say “only supports 2D textures” or “only supports 3D textures” then it’s not clear what we’re talking about
• KN: WebGPU already supports compressed 2D textures
  • KG: They’re specified via 3D upload signature, but the texture type is 2D
• KN: In WebGPU, you’d make a 2D texture, a 2D texture that has multiple array layers.
• CW: Issue 4705 is the one I filed. I have concerns about guaranteeing … With respect to texture compression, you either get BC, or you get ETC2 + ASTC. If you fall in the BC bucket, then you get 2D compression and sliced 3D compression guaranteed. But if you’re in the other bucket, you don’t get sliced 3D compression. We can guarantee it on the BC branch, so a developer might think it’s good to use on the other branch.. If you update your code to switch from one to the other, then it won’t work.
• KG: There are 2 ways to do this. One is to make it so that you have a different extension that allows you to sliced 3D compressed textures, even on BC (even if it’s supported everywhere). Every implementation of BC will always support that extension. The author is introduced to the concept that it might not always be there (Even though it is always there on BC). Or you could say the ETC2/ASTC suffix has a “-2D” suffix on them.
• MM: No other API separates 2d from 3d-sliced BC, think we shouldn’t either
• CW: WE can’t rename extensions
• KG: You’d add both names, add a console warning and a deprecation for the old one
• CW: This is much harder to do than to change some validation rules.
• CW: Changing the name of the extension for this is asking for a lot. It’s a good solution, but apps have the old names hardcoded.

• See if we can meet next week, Kelsey, Kai can be here, ask Mike?
• Oguz: Just a suggestion. For sliced 3D, it might be better to just reference 4701 and 4705 as the 3183 is complete in itself with the change to only support BC, it might be confusing if that issue is linked rather than the active issues which are self-contained enough. Thank you for your consideration.
  • KN: Agree, added items to agenda requests accordingly.
• Agenda requests
  • (timebox?) Consider moving sliced 3D compressed BC texture to an extension. #4705
  • (timebox?) ASTC Compressed for Sliced 3D as Extension #4701
  • Validation errors from Promise-returning operations
    • Clarify that create*PipelineAsync must not generate a validation error #4714
    • mapAsync early-reject doesn't generate a validation error #4690
  • Consider if there's a much better name for "image copies" #4573
  • Depth Bias does not affect line and point primitives. #4729
  • Compatibility Mode: Support OpenGLES devices with zero SSBOs and image uniforms in vertex, fragment stages #4721
  • (stretch) Hardware feature levels (and compat) #4656
  • (timebox) Push constant proposal #4612
  • (not before the 24th (which?)) Presentation about GPU memory isolation from UCSC