GPU Web 2024 01 24
Corentin Wallez edited this page Feb 6, 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: Ken
Location: Google Meet
- Administrivia
- CTS Update
- “Tacit Resolution” Queue
- API should be exposed to ServiceWorker #4197
- sampleCounts of 2, 8, and 16 #4446
- WebGPU Compat
- ASTC textures aren’t supported until ES 3.2, can’t require them in compat
- Milestone triage of issues with no milestone
- Implementation Updates and Developer Tooling
- Agenda for next meeting
- Apple
- Mike Wyrzykowski
- Google
- Corentin Wallez
- Gregg Tavares
- Kai Ninomiya
- Ken Russell
- Loko Kung
- Stephen White
- Microsoft
- Rafael Cintron
- Mozilla
- Jim Blandy
- Kelsey Gilbert
- Teodor Tanasoaia
- Mehmet Oguz Derin
- Nope
- KN: CTS week here on the Chrome team. Tint team driving it. API side, less organized, trying to address longstanding failures and/or incorrect tests. Expect new tests. :)
- Nothing this week
API should be exposed to ServiceWorker #4197
- JB: This the API is already exposed on WebWorkers, then it seems fine to expose it. Since ServiceWorkers are persistent there's a bit more risk of abuse, but implementation will have to deal with that already. So seems to make sense to add.
- (... do this in SharedWorker as well…)
- KN: We want to do this in Blink as well, no reason not to.
- MW: Thumbs up.
sampleCounts of 2, 8, and 16 #4446
- CW: TextureCapability discovery?
- JB: way WebGL handles this - you ask for whatever sample count you want, and the validation makes sure you get something similar to what you ask for. But the impl can give you e.g. 4 if you request 3 samples. Take similar approach? Is it true - no way to get the multisampled contents of a buffer off the GPU?
- KN: in WebGPU there's a texture function (in shaders) where you can get samples by index. So you need to know the number of samples you got.
- KG: sample / load / fetch is the thing. Can't sample from them but can fetch from them.
- CW: in WebGPU since you can fetch samples you need to know how many samples are in there.
- JB: if user asks for a number, perhaps giving them more is OK.
- KN: would like to explicitly list which sample counts you get, and what their sample patterns are. Be strict about it. Difficult to write portable app? Can always use a sample count of 4.
- JB: more burden on content author to adapt to what's available.
- CW: D3D12/Vulkan have standard sample positions. Metal too? Each sample's location is known exactly.
- KN: that's how things work in the current spec and would like to do that for this too. But means we can't automatically upgrade sample counts.
- JB: so we'd add more entries to the standard sample patterns?
- KN: yes.
- There are portable sample patterns for up to 16 samples.
- KN: D3D defines these in their spec. And yes, Vulkan's spec matches. Has been standardized for a long time.
- MW: in Metal you can set the sample positions programmatically, so we can match them.
- CW: we're OK for sample locations but how do we expose this, and now or later?
- GT: do we want to do it like WebGL?
- KN: I'd like to be strict, here are the ones we support, and validate that.
- JB: I like that better too.
- CW: OK, new texture capability. Per-format? Or, globally, support 8, or 2? I don't know if HW supports it for everything at once.
- KN: think they don't. Limits are usually lower for bigger texture formats, I think. Need more investigation. Vulkan gives you bitmask of what's supported, per-format.
- CW: OK, we agree we will expose sample counts/locations but need more investigation of exactly how to do so, studying per-API.
- KN: D3D requires 8 on everything except RGBA32 formats. No guarantees about 16. ("Other multisample counts are optional.")
- JB: wgpu's interface - we have 4 separate texture format feature flags for MSAA x2, x4, x8, x16. 4 independent features.
- JB: procedural point: Compat issue is huge - let's file more smaller bugs about items.
- SW: agreed, will do.
Compat: renderable float16, float32 textures #4417
- SW proposal was: we'd like to require it. Gregg looked into this - have yet to find a device that doesn't support it.
- GT: didn't actually successfully find a device. Mostly Samsung J3/4/5 Prime. Also Samsung A7. But there are multiple hardware versions with the same model name. The ones I got didn't have the GPU I aimed to test. Also slow - in WebGL, were running a spinning cube at 10-20 FPS.
- KN: gives us reasonably good indicator of perf of that device class. Probably similar perf on the other GPU (not great).
- TT: Mali T720 had biggest chunk of devices. Any data on that?
- GT: I don't have any.
- KN: GPUInfo database didn't have any T720 devices that had this. 860 / 760 had some support, but no reports from 720. So it probably doesn't support it at all.
- TT: OK. Also small number of devices for Firefox.
- SW: let's require for now and if we find a widely-used device capable of running WebGPU reasonably, and doesn't have this support, revisit.
- TT: OK.
- SW: thinking of saying - you have to support BC on desktop or ETC2 on mobile, one or the other, instead of ETC2+ASTC on mobile
- TT: one extension that can be used. Raised on the larger thread.
- KN: looked into that, not enough support, can't be relied on.
- TT: older drivers didn't have this support.
- KN: this req in the spec (mobile: ETC2 + ASTC) was initially aspirational. Just barely able to do it. Think it's OK for Compat to just mandate ETC2. Feature flag for ASTC will still be there.
- CW: Should decide what milestone Compat is in, since right now it doesn't have a milestone. Was going to suggest 1 or 2.
- KR: I'd like to suggest M1 because it won't impose undue complexity on any other impl and Chrome would like to get this out sooner rather than later. And it's already in the spec.
- (Silence)
- CW: OK, let's consider it M1.
- Let's do triage offline.
- JB: in firefox, aiming for Win/Mac/Linux around June
- GT: "let" syntax in shaders? One of the major compatibility issues right now.
- JB: yes, this is definitely on the list.
- Lots more discussion of Firefox's status.
- JB: congrats on DXC shipment in Chrome, impressive.
- Questions about this and how it might be done in Firefox too.
- MW: at Apple, made WebGPU an option in Safari Technology Preview
- Continued work on passing WebGPU CTS
- Can't comment on timelines. But once passing CTS, plan to ship.
- Communicating with Unity folks, getting their WebGPU exports running.
- Boat Attack, Skinning and Particles demos from their November blog post are all running!
- JB: a bit concerned about using the CTS as a work list. We're mainly using examples/demos for that.
- Also:
- https://github.com/brendan-duncan/webgpu_inspector
- Can capture WebGPU API calls, makes them easier to debug
- GT: I've used this one, he has another one - DevTools extension for Chrome, not sure if tested in Firefox.
- GT: I'm working on a couple of similar things:
- Can install extension, check a box, adds creation descriptor to the object that was created, so you can look at it in the debugger. Doesn't do deep copies of the descriptor objects, so if you mutate it it won't show the right thing.
- Tack on texture to createView.
- Track pass state. Can look at pass object in debugger, see what BindGroups / vertex buffers are bound, etc.
- Mode where it puts pushErrorScope / popErrorScope around each call. So if you see an error, you get a stack trace.
- Brendan helped with this a lot. He wrote the WGSL parser so I can get offsets of structs for example.
- Webgpu_recorder: https://github.com/brendan-duncan/webgpu_recorder
- Webgpu_inspector: https://github.com/brendan-duncan/webgpu_inspector
Webgpu-dev-extension: https://github.com/greggman/webgpu-dev-extension
- Skip next week? Out of topics for right now
- But, please do add topics here if you'd like to meet
Agenda
- Validation for setViewport is incorrect #4461
- HDR stuff next Atlantic meeting.