Chair: BJ
Scribe: BJ
Location: Google Meet

• Administrivia
• CTS Update
• Allow copyExternalImageToTexture for all renderable formats #5323
• Compat: Rename compat limits to clarify they're compat-only #5322
• [immediates] minimum maxImmediateSize should be 16? #5320
• Finish texture swizzle discussions?
  • Should we disallow creating views that only includes COPY_* usages? #5317
  • Should texture swizzle move usage restrictions from createView to createBindGroup/beginRenderPass? #5298
• Maintainer access for the WebGPU landing page #5324
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Brandon Jones
  • Geoff Lang
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Loko Kung
  • Stephen White
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
• Nvidia
  • Anders Leino
• Albin Bernhardsson
• Connor Fitzgerald
• Oserebameh Beckley
• Lee Mighdoll

• None

• None

• Gregg feels strongly that we shouldn’t support snorm formats
• JB: If it’s just to make the spec nicer, we would prefer not to support the expanded formats. At the moment we have to manually encode these on the CPU.
• KN: We haven’t explicitly have anybody ask to copy into 16bit unorm formats, but easy to see why they would want to eventually. E.g. 16-bit PNG. Could copy to float32, but waste of space.
• KN: Could exclude RG11B10ufloat
• JB: Don’t want to stand in the way of supporting things people would find valuable.
• KN: [only] slightly complicates spec to exclude ufloat. But also if you don’t implement immediately people may not notice?
• GT: May be more important soon. MacOS recently allowed for HDR screenshots.
• KN: Good point.
• KN: Prefer to say all unorm and float formats, but could also put a note [to ourselves] saying to update the list of supported formats as they are added.
• MW: Including integer formats as well?
• KN: No. No good defaults for int, like snorm. Only unorm and float.
• MW: Sounds good.
• GT & JB: Sounds good.

• KN: From F2F discussion. CW suggested compromise of renaming limits to indicate that they’re compat only. Thoughts?
• JB: Mozilla would rather not change it.
• MW: Seems like no change needed if this is the extend of the compat changes.
• CF: Yeah, feels weird to prefix.
• KN: No objections to leaving as is!

• KN: Was hoping that Shaobo would comment on it, but I filed this quickly and forgot to ask.
• JB: Mozilla was surprised. 16 is pretty restrictive. Why would it need to be so small?
• KN: I don’t know either. Will follow up with Shaobo.
• CF: Feels weird. Other places in the spec where you can create a valid program that runs out of space in root signature. Being hyper conservative here feels like the wrong solution. 256 is obviously inviting problems, but 16 seems very restrictive.
• KN: I think we set this to 32 in D3D. We could also say that dynamic offsets are included in this limit. May be a D3D only approach. Offsets were intended to be a specialized form of push constants.
• CF: Feels like there needs to be another limit which is computing the space in the root constant. Similar to render target bytes for Metal. Haven’t tried it, but I feel if you max out your bind groups you’ll fail to create a pipeline due to running out of root constant space.
• (KN and CF discuss different approaches to applying buffer offsets)
• KN: We can discuss later, but maybe we should have a fixed limit?
• CF: D3D12 root signature is 256 bytes, which means 64 32bit slots
• KN: Only applies to D3D. Don’t really want to add that. Could be rolled into maxImmediatesSize in some way. Should check other backends to see if including offsets in that limit would adversely affect them.
• CF: Vulkan doesn’t care. Will happily make the driver spill to a buffer.
• KN: Pretty sure Metal also will.

• KN: Not actually related to Swizzle. Views with only copy usages would be useless, so should we validate?
• JB: Seems like catching useless behavior earlier is ideal.
• KN: There are other cases we don’t validate, like 0-sized buffers, because the size may be dynamic.
• JB: It’s nice to have things behave consistently across the spectrum of possible values, but this seems unlikely to arise programmatically.
• CF: I’m gonna disagree. In any dynamic render-graph-type app you could end up with this. Currently you can always make a texture view, but this becomes another “gotcha” you have to account for.
• JB: Not following? Would be building up command buffer based on the graph, you would know what the needed usage will be.
• CF: If the texture only contains copy usages then you can never create a view.
• JB: But that texture is useless? You can only read zeros out of it.
• CF: Agreed, but it’s convenient to make it consistent.
• JB: This is the question. We don’t validate e.g. texture with only COPY_SRC. Seems inconsistent to validate this but not other cases.
• KN: We do validate textures with no usages, this would be the same but for views? We could even filter out the COPY usages in createView since they don't do anything, then we would actually get usage=0.
• JB: (Missed what was said)
• KN: Some day there may be a use for copy only texture views?
• JB: Question is if it’s more helpful to complain at the point that something incoherent HAS happened or MAY happen.
• KN: Strictly from a user-facing statndpoint no clear answer. If there is a limitation it makes sense to surface it.
• AB: Looked at it: Creating a texture view with usage 0 is currently valid, it means inherit from texture.
• JB: 0 means inherit, so 0 doesn’t mean 0. Does the API let you say “No, I ACTUALLY want 0”?
• KN: No.
• JB: I think unless there’s platform limits
• BJ: In previous cases in WebGL, we've had situations where the usage was odd but not necessarily limited by the backend, so we surfaced a warning - we know you did something useless, you can skip it.
• JB: Only way to silence that warning is to not do that thing.
• KN: Main motivation is to avoid a case where the implementation needs to skip a backend call because it would be invalid. Otherwise leave it alone.
• JB/CF/MW: *General noises of agreement*
• KN: Good, then leave as-is unless we find a backend requirement, maybe add a warning.

• GT: Current texture swizzle proposal gives a validation error if you have a swizzle with storage/binding usage. Will require you to always subset the usage at creation time. Suggests moving the validation to actual usage as a storage binding/render target. Shouldn’t impact performance, makes API easier to use.
• CF: We have logic for inheriting usages. Could we say that if swizzle is set don’t inherit render/storage.
• GT: Was suggested, makes it hard to surface errors when you use it wrong. Implementation needs to track more state to give a good error.
• KN: Concurs. Do you know if we need this validation? Could we say if you use texture view as attachment then the swizzle doesn’t apply?
• GT: Doesn’t work for Metal
• KN: Don’t understand the validation error in Metal
• JB: Can’t some hardware apply swizzles to render targets? May want this in the future, would be a shame to block that now.
• MW: In Metal we could allow render attachment usage and ignore the swizzle. May not be allowed by validation layer but we could create a new view.
• KN: Would like to avoid multiple backend views for one frontend view.
• CF: Agreed. User should be aware of consequences of their actions.
  • JB: thumbs up
• KN: My understanding of Metal error was that:
  • In order to use swizzle, it has to have (the equivalent of) TEXTURE_BINDING. Swizzle is ignored when used as attachment.
  • Not: if you use swizzle, you cannot have usage RENDER_ATTACHMENT.
• GT: *Reads message*
• KN: Could be interpreted a couple of different ways.
• GT: Are you saying we should ignore the error?
• KN: No, that was for a depth stencil issue. Would like to understand the Metal message regardless.
• MW: same restriction applies to storage textures as well in Metal.
• KN: Do you know what the correct interpretation of the message is?
• MW: will check - think the hardware doesn't exist when writing to the texture to apply that swizzle operation.
• KN: In the first interpretation swizzle would be ignored when used as an attachment, in the second case it’s not possible to use as an attachment.
• MW: My understanding is that you CAN write to the texture but the swizzle is ignored when used as an attachment/storage.
• KN: Might try in a sample Metal app. Mostly for internal need to get rid of warning. Not relevant to this feature unless we change its validation so it allows this and silently ignores the swizzle for storage/attachment.
• GT: Do we need more info to make a decision?
• KN: No.
• MW: I prefer leaving validation at createView.
• JB: Moz's preference as well.
• KN: agree with Gregg that this is ergonomically painful. To use swizzles you have to subset your usages every time; no need to force people to do that.
• JB: Moz's position isn't a strong objection. Main question - more helpful to report problems to user as soon as the possibility arises, or at the point where it's an actual problem? Example - are people going to get errors from this when they start a render pass, and then wonder why the view is the way that it is? If so - we should tell them when they create unusable views.
• KN: Talking about a view with both texture binding and render target. It’s a usable view, just invalid to use as an attachment.
• JB: so the situation hasn't become absurd at view creation time.
• MW: if developers are passing RENDER_ATTACHMENT and STORAGE_BINDING usages when not needed, that's undesirable. Optimizations that can be made when these aren't set.
• BJ: we do have prior art for this. Render attachment or storage binding usages - format has to be applicable. Applies to the inherited usages. Strict backend requirements that led us to this. Know this usage / setting are incompatible here - we'll allow it. Analogous to doing this at view creation time.
• KN: Would be nice for these to be consistent.
• GT: what's consistent? Haven't needed to subset usages in the past ~3 years of using the API. Want things to work as expected.
• JB: want more info about whether there are perf implications of unneeded usages.
• GT: separate topic. Nothing to do with swizzle.
• KN: there would not be a perf issue relating to swizzle, because we can internally remove the usage if a swizzle is requested.
• KR: Seems to me like Gregg's proposal is the way to go. Fail at the point that the nonsensical usage occurs.

• JB: Rubber stamp for this?
  • CW / KN / BJ: thumbs up
• JB: Mozilla in favor
• Added Lee Mighdoll (@mighdoll), Stefan (@stefnoch), Mathis Brossier (@k2d222)

• Just a comment - copyExternalImageToTexture with HTMLCanvasElement is a hot path for some game engines. Firefox and Safari are 240x slower than Chrome WebGL on M1 Mac. Chrome also has perf issues on Windows. I’m bringing this up, one to make sure people are aware there’s lots of room for improvement. But also, what if any responsibility do we have here. I get we can’t make promises, but it’s frustrating for devs to work with a platform with these cliffs.
• JB: Please file an issue for comments like this, don’t want to lose track of it.