GPU Web 2024 02 14
Corentin Wallez edited this page Mar 5, 2024
·
1 revision
Note that unless stated otherwise this is a GPU for the Web community group meeting and not a working group meeting.
Chair: CW
Scribe: KR
Location: Google Meet
- Administrivia
- CTS Update
- “Tacit Resolution” Queue
- Extended brightness range rendering #4239
- Latest proposal
- Validation for setViewport is incorrect #4461
- Should we constrain the location of user input-output stage variables WGSL #1962, the return.
- Compatibility mode:
- Agenda for next meeting
- Apple
- Mike Wyrzykowski
- Google
- Austin Eng
- Brandon Jones
- Christopher Cameron
- Corentin Wallez
- Gregg Tavares
- Kai Ninomiya
- Ken Russell
- Stephen White
- Microsoft
- Rafael Cintron
- Mozilla
- Jim Blandy
- Teodor Tanasoaia
- Nvidia
- Anders Leino
- Ken: Khronos is likely to sponsor a WebGL + WebGPU meetup at GDC the evening of Wednesday March 20, if you are available in the area, please consider coming.
- Kelsey: The WGSL conference call was renamed to "CG …" just want to clarify that the meetings (including all API meetings and WGSL meetings) are (and practically always have been) CG meetings, not WG meetings as folks sometimes say colloquially. That colloquial use is fine! But I wanted to clarify that these meetings are CG unless very explicitly and actively noted as official-WG meetings.
- Kai: Gregg fixed bugs that Mike reported yay!
- Corentin: Still pushing WGSL tests a lot.
- Stephen: Ben made a significant reduction in number of subcases (without loss of coverage)
“Tacit Resolution” Queue
Extended brightness range rendering #4239
- Time box 20 min (12:30 PM Pacific)
- Latest proposal
- See gamut demo
- CC: some WebGPU spec text isn't clear about what happens when you use rgba16float and go above (1.0, 1.0, 1.0)
- Says luminance is clamped - not quite correct
- Want to change spec text to be correct
- Converted from canvas's color space to screen's color space
- In screen's color space, clamped to 1.0 interval (see the issue above for details)
- Positive responses from Adobe and others
- KG: feedback - would be good to split this into two. First, correct the current spec text; then add the new functionality. We're in agreement (or very close) about the spec text.
- sRGB-HDR content on sRGB monitor - will that show the same thing on a P3 HDR monitor as on the HDR monitor you authored it on?
- CC: Believe the colors are similar (shows pictures, but just pictures).
- RC: only concern - implementable easily on Windows when you don't use Chromium's compositor?
- Positive response from the CG overall!
- CC: I'll start writing PRs in a bit. :)
Validation for setViewport is incorrect #4461
- KG: not so confident about this being a scaling factor for the Z coordinate. Can we write tests for this and get portable behavior for it? If so, great. An expansion of behavior.
- MW: there are tests for this; it's how I caught the issue.
- CW: not sure the test verifies the operation.
- KN: correct, it's just a validation test.
- KG: will rendering based on this be reliable and portable?
- CW: can take action to write operation test for this in the CTS. If it passes on all backends we'll report that to the CG and move forward with the change.
- KG: sounds good.
Should we constrain the location of user input-output stage variables WGSL #1962, the return.
- CW: we missed a constraint from the Vulkan spec. # interstage variables, and # interstage components available, in the limits. Thought Vulkan spec freed up padding between interstage variables; normally variable takes <= 4 components (think vec3 rather than vec4). Turns out, Vk spec says "each location takes 4 slots". Padding is taken into account.
- CW: don't think anybody uses that. In corner case where you max out all input locations, things fail with Vulkan validation errors.
- CW: suggest changing the spec to count 4 components per variable.
- KN: wanted to see if that limit corresponds to anything on other backends. Don't remember. Is there something on D3D? Regardless, if I understand Vk correctly, each scalar float takes 4 slots?
- CW: yes.
- KN: ok, so makes significant difference in accounting. Potentially 4x less space than we thought.
- CW: yes. But, … if in base limits you have code that won't work any more - and this will just be code similar in corner-case situation to the last one in the comment thread of the issue.
- KN: think unlikely to cause issues. Assume it would already not have worked on some devices. Is this limit now redundant with the other one?
- CW: maybe.
- KN: can take the other limit & make sure it doesn't exceed Vulkan limit / 4. Slightly different accounting for builtins.
- CW: if we do this, need to lower base limits from WebGPU spec.
- KN: 16 interstage variables right now.
- CW: APIs do this because interpolation is done per vec4 in hardware. Hard to pack things. flat, non-flat, perspective, centroid, etc. Don't think we can emulate things.
- CW: like to suggest each variable counts for 4 components, and see. Maybe these two limits are redundant then.
- KR: suggest we do the change, try it in Chrome Canary, see what real-world content breaks. Some sophisticated partners like Unity already pack scalar uniforms into vec4s themselves, so would not affect them.
- KN: think we have to do the homework - see what has to change in the spec, see if anything's redundant, and make a proposal.
- KG: no other feedback?
- JG: if we have to accept the padding, that's the way it is.
- CW: we could reduce the limits, like maxInterstageVariable limit. But it's a worse solution.
- Agreement: spec PR, is it redundant by looking at limits in various APIs?
- KN: might be - need to lower limit instead, because other backends want to use the accounting we're already going.
- CW: let's discuss more.
- Multisampled textures are uncopyable #4468
- KG: generally uncopyable in OpenGL. Made some lists. Thanks Gregg for finding this. Only thing - if possible to map gl_FragCoord to int sample for texel fetch, you could target to do a blit-via-draw, maybe.
- CW: need micro-triangles for this? Can't force sample-rate shading.
- KG: yes, would be bad/gross.
- KG: would be easy to say, for now, that you only get blitFramebuffer's behavior. Gregg's PR sounds good to me. Approved it on our side. Requires single-sampled textures during copy.
- CW: consensus to merge.
- Provoking vertex issue #4489.
- CW: think we raised this at a Compat mode F2F. And then we forgot about it.
- KG: Moz met earlier to discuss. One idea: add a flat_any or flat_dontcare to the shading language. Useful for anyone who needs it. In Compat, we'd forbid the one that needs to be flat_first. Don't want to implement that on ES 3.1. Can probably do something similar to what ANGLE does on D3D11. Tantalizing. Reason you want "flat" here is that you only put the data on one vertex - it's because ints have to be interpolated via "flat".
- KG: e.g. in WebRender - we wanted a DontCare option. All 3 verts of tris have the same data. Think that's common for apps.
- Gregg posted that you get untestable behavior. Just underconstrained, IMO. You get one or the other. Impl might be flat-first or flat-last.
- KG: in spec, we'd say it's incorrect to use flat_any if there's any behavioral difference between the two.
- KG: don't see a good way to get around the behavioral difference without writing the polyfill or enabling features.
- CW: ANGLE uses geometry shaders for this.
- SW: not sure ANGLE's impl handles indirect draws.
- KG: think they use them.
- SW: Metal's backend supports this vertex swizzling too. Not sure if it handles indirect draws. (99% sure no.) Concerned about emulation & performance cliffs. Like your (KG's) solution. Will read it more carefully.
- SW: other options: adding different extensions to bring this back. Has to run on more than ES. Need it to run on D3D11, Vulkan, etc.
- KG: like the idea that impls should replace "flat_any" with "flat_first" where possible. Best tradeoffs for real-world use cases.
- SW: Kai mentioned that some folks use this for uses where you don't have the same data for all 3 vertices.
- KN: exporting optimized models, you get correct shading based on normal being first or last vertex. Would otherwise need to duplicate vertices. Convert to tri strips, etc.
- KG: on balance, best to say that in Compat, you can't rely on one or the other. It's at package bake time that this is decided.
- CW: in WebGPU you have storage buffers. Could export that, you have the triangle indices…
- KG: we'll think about it and come back with something that sounds good.
- CW: also - folks developing WebGPU developer tools (outside the browser). On some places, in dev mode, "flip the provoking vertex" - could be useful.
- Have homework. Not sure we'll get to all of it by next week.
- Light on topics. Meet again in 2 weeks? Make progress offline?
- Thumbs up generally
- Agenda