Chair: CW

Scribe:

Location: Google Meet

• Administrivia
• CTS Update
• Compatibility mode: provoking vertex differs between OpenGL and WebGPU #4489
• Compatibility Mode: Support OpenGLES devices with zero SSBOs and image uniforms in vertex, fragment stages #4721
• Compat: Should requesting compat mode on a device that supports core, return core or compat? #4731
• Compat: sample locations don't match the spec in OpenGL #4804
• Compat: Disallow usage of depth textures with non-compare sampling functions. #4970
• Compat: Disallow texture*() of a texture_depth_2d_array with an offset #4513
• Agenda for next meeting

• Apple
  • Mike Wyrzykowski
• Google
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Stephen White
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
  • Teodor Tanasoaia
• Albin Bernhardsson

• CW: next meeting the 4th of December, next one in the new year.
• CW: Started the CR process, transition has been announced, we should have it happen in finite time.
• CW: Lots of milestone 1 issues, if you care about specific ones please list them at the bottom of this agenda.

• MW: not formally objecting or requesting change, but seems odd to have this feature in the core spec when we're presenting the developer with an option, and both options do the same thing in core implementations
  • Extra typing is so minimal that don't feel strongly about a change
• JB: Moz would like to leave things as they are
• MW: OK
• Will close.
• CW: we already noted down the difference that will be in Compat.
• SW: fine. Good with it as written. Already implemented in Chrome.

• CW: Can we agree to the PR now?
• SW: not a PR right now, just a branch
• CW: seems there was already consensus to add these limits.
• SW: we had the vertex one, decided we need to do the fragment one. Any disagreement on adding the fragment limits? (No.)
• TT: sounds fine to me. You can just add me as a reviewer to the PR.
• SW: can I make a PR against a PR?
• No.
• KN: can make a PR containing both commits…painful.
• CW: consensus to add the limits to fragment shaders. Consensus on limit values?
• SW / KG: default will be 0 for Compat.
• SW: limits are 0 in ES 3.1, 4 in ES 3.2, interestingly.

• GT: presented intro
• CW: intent was always that for Compat, we want developers to be able to easily test Compat if they're on a browser that supports that feature level. They test on their machines, it'll work on all browsers that support Compat. Otherwise they can't really test, if they were auto-upgraded to Core.
• JB: Gregg, under your proposal, how will developers that want to validate against Compat do so?
• GT: they'd have to pass in some flag or something outside the browser to get the behavior.
• KR: could misspell the command line flag…would rather that requesting Compat return Compat if the browser supports that.
• KN: OK with either way - and I think it's a UA decision - only thing that concerns me is Hyrum's law, people depending on Compat because of slight differences. A few differences which are not super hard to accidentally rely on, in a way that'd break on an impl that doesn't support Compat. [Either way we can tell people to test Chrome with a flag to try a browser that does the opposite behavior.]
• CW: WebGPU with features/limts are opt-in. Pushing devs toward max portability, even if annoying sometimes. My app supports Compat - your app will get Compat for max compatibility. If it works on your machine, it'll work everywhere you expect.
• KN: I think that's more important than people accidentally relying on Compat.
• CW: only thing that people can rely on in Compat is vertex stuff, like provoking vertex.
• KG: we discussed this before, think we should have strong reason to do so again. 2 use cases: i want "compat or core", or i want to check compat on a browser that supports core. If we make it not auto-upgrade, and i want it to auto-upgrade, i can write the code to do 2 different calls. If i want compat, can write the code to ask for it. If it were the opposite - in the auto-upgrade case i'd just ask for a thing. But if i want to check compat - and we do want people to do so - it's difficult and depends on the browser. Mean of all these options is to keep the status quo. Think we should pursue more graceful auto-upgrade in the future, but right now think it's tolerable to make the 2 adapter requests.
• CW: think that's compelling, thanks for the description. Unless strong objection, let's close as WontFix.
• GT: <thumbs up>

• CW: what's possible in Compat w.r.t. sample locations?
• GT: can barely remember :) Can't look at sample index or sample mask, but can call textureLoad on a multisample texture. So can draw over corner of a texture that's sample 0 and then textureLoad sample 0 and they'll be in different orders.
• GT: think we should polyfill because if you ask for index 1, should get index 1. This is textureLoad, not textureSample. Expect to get what I asked for in that case.
• JB: in this example, sample index 0 isn't actually disturbed in OpenGL.
• GT: use sample 3 then.
• JB: like your suggestion that since we have a low-cost workaround that works for everybody, Mozilla likes the suggestion. Especially since no change to spec. :)
• CW: not just that order of samples is shuffled - they might not be in the exact same position.
• KN: nothing we can do about that. Spec has to loosen that guarantee in Compat. Can say order of quadrants is the same, but samples could be in different places.
• CW: OpenGL spec doesn't specify the sample locations.
• SW: surprising if same device in Vk and GL had different locations.
• CW: it is configurable on a lot of hardware. :)
• KN: on Vk, small number of impls that don't report standard sample locations. On GL I don't think there's a way to query it. On Vk , couple of really old NVIDIA devices, and Broadcom D3D?
• GL: you can query this in GL FWIW.
• CW: if we can't change the sample locations, or spec says nothing, people probably won't realize the sample pattern's slightly different.
• SW: I agree. Quadrants are known broken, let's fix that, and sample locations are unknown how broken they are. Revisit when we have more data.
• KN: there's a test for the positions. If they fail, we'll find out.
• CW: everyone's fine remapping quadrants, and is OK not saying anything about non-standard sample locations, and seeing later.
• KN: yes.
• Resolved.

• TT: Kai also mentioned it's even more general than this. If you want 2 bindings, one doing sampler comparison and one with normal sampling, can't have that either.
• KN: said that yesterday, but realized that we can't do that anyway. We're binding a combined sampler/texture anyway (I think). Think there's no problem here. Already a rule that says, each texture can only be used with 1 sampler for this reason.
• CW / GT: right.
• CW: it's actually that you can't use multiple different views of a texture in the same draw/dispatch.
• SW: issue #935 (?) in the proposal.
• CW: could we bind the "compare" version of the sampler instead?
• SW: we do have placeholder samplers we bind. Think this might work.
• GT: the failing tests are not failing because of udnefined behavior. I gave an example - if you use textureSample and generate GLSL for it, it's undefined behavior per the spec.
• SW: I need to look at this more. Revisit later?
• KN: my understanding - you use comparison sampler but don't set comparison mode on the texture, and vice versa, it doesn't work.
• KG: and there's no way to combine the texture/sampler differently in 2 different places. ES 3.0, you can't allow using textureSample on a depth texture sampler, if you also used it in the same draw call with a different sampler.
• CW: because it's a texture parameter.
• GT: different problem. Issue is that it doesn't work with even one sampler.
• KN: isn't that because you haven't updated the texture parameter?
• GT: you have sampler2DShadow, if not set to compare, it's undefined behavior.
• KG: saying you can't generate a bindgroup with both of those.
• GT: we have tests that do this.
• KG: GLES spec says you can't rely on that.
• GT: correct. GLES spec says it can't be used. WebGPU spec says it can be used.
• KG: agree that we have to make a spec change.
• KN: I was wrong, thought we had a restriction that we don't have.
• SW: we need to prevent - if we don't already - (does the aspect handle this?) -
• KG: if you think impls can handle this internally, interested to see.
• SW: 2 binding points can't do different things.
• GT: the issue doesn't require 2 samplers. It only requires one.
• KG: right now you can have 1 shadow sampler, can call textureSample on it and textureShadowSample on it. No way to implement that in GLES.
• KN: in WGSL those are 2 different sampler types.
• KG: can call textureSample on a depth texture today. Remove that in Compat?
• SW: sounds like something we need to forbid in the shader.
• KG: yes, in Compat you wouldn't have overloads that take texture_depth. Get rid of half the overloads.
• SW: or, allow only one in a shader.
• KG: goes against the intent of the spec.
• KN: seems similar to what we do for filtering.
• CW: in Compat - is it true you can bind a depth texture to texture_2d, f32?
• GT: yes. As long as you mark it NEAREST filtering.
• SW: NEAREST applies to Core too.
• CW: for this reason - think we can say, texture_depth, you can't use textureSample on it any more. If you need to, you can bind it as a texture_2d, f32.
• (nods all around)
• CW: I vote for the simple solution, remove the overload. Decide at shader creation / bind group layout time.
• SW: that's when you set the GL state on the texture to one or the other?
• CW: yes.
• KN: have to do that lazily, at draw calls.
• SW: but it's the type of binding you use to know which mode to use.
• KN: this is fine, think both impls are possible. Let's do the simpler thing and see what happens. If apps don't port easily, we can reconsider and do something more advanced.
• CW: any concerns?
• (none)
• CW: OK, let's go in this direction. Resolve this issue.

• SW: here, GL has weird missing texture functions. Teo suggested we can work around using textureGradOffset. Had agreed to add this restriction to the spec. I tried Teo's workaround and it works, so I suggest we don't land this.
• AB: if we go with previous suggestion, would this still be an issue?
• SW: think it is - the compare functions are also affected.
• CW: there's textureSampleCompare with an offset, but nothing with a Grad.
• CW: seems that might be possible to emulate Grad version with GLSL, are folks OK not adding the limitation then? Looking at Stephen's code linked from the PR, it's reasonably small / easy workaround.
• JB: just need to capture the coordinates in a temporary, apply ddx / ddy yourself.
• CW: sound OK on Naga side?
• JB: yes, low-cost polyfills are good because we increase WebGPU's portability.
• CW: suggest we resolve to not take this - retroactively remove because we have a simple workaround.
• KN: were we saying something about compare versions of these functions?
• SW: yes and I'm confused now because my "compare" samples weren't doing compare.
• CW: let's tentatively agree to use the workaround if it's simple, but we need to revisit this because we're trying to remember things live in the meeting.

• CW: everything Compat that's not API-resolved.
• GT: for Compat, there's float32 / float16 renderable issue.
  • SW: we discussed at the F2F, resolved to make it a feature. I put up a PR about it (today).
  • MW: problem with making this a feature is that it breaks stuff on a browser that supports Core but not Compat (?)
  • KN: we'd need to put it in Core and say it's guaranteed to always be there.
  • SW: seems similar to Limits issues where we have to put them in Core as well.
  • (EDIT: KN: filed separately as #4987, and added to the agenda below)

• How to add features and limits for Compat after Core ships? #4987
• Compat: renderable float16, float32 textures (discuss independently of #4987) #4417 (approved)
• Compat: Limit the number of texture+sampler combinations #4989
• Compatibility Mode: GL_MAX_COMBINED_* limits in OpenGL ES #5003
• Resurrect vertex formats dropped for macOS < 10.13 (feature detection) #4549
• Create timestamp-query2 for tiled architectures #4995
• Validation requires vertex buffers to be set, even if they are unused #4999
• (late; at least socialize) Compatibility mode: support devices without integer texture format multisampling #5004
• (maybe) Viewport rect must lie entirely within the current attachment size? #373