GPU Web 2024 03 13
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
- Compat burndown
- Compat: Validating out viewFormats / view reinterpretation #4404
- Compat: validating out "2d" of more than 1 layer #4378
- Compat: Disallow vertex stride of 0 #4515
- Compatibility mode: provoking vertex differs between OpenGL and WebGPU #4489
- Compat: Disallow textureLoad() of depth textures in WGSL via validation. #4512
- Compat: Disallow texture*() of a texture_depth_2d_array with an offset #4513
- Compat: Disallow bgra8unorm-srgb textures. #4514
- Allow using a (float32-filterable 2d single level) texture view for an externalTexture binding. #4504
- createTexture does not validate viewFormats against usage #4426
- (stretch) Clarify handling of out of range color values #4499 (issue #4239)
- (stretch) Add extended range #4500 (issue #4239)
- Agenda for next meeting
- Apple
- Mike Wyrzykowski
- Figma
- DM Liao
- Google
- Ben Clayton
- Brandon Jones
- Corentin Wallez
- Gregg Tavares
- Kai Ninomiya
- Ken Russell
- Mozilla
- Jim Blandy
- Kelsey Gilbert
- Teodor Tanasoaia
- Nvidia
- Anders Leino
- Mehmet Oguz Derin
- Corentin: Do we want a F2F?
- Last one was Spring 2023, maybe a new one this year?
- We have a lot of work right now, maybe this autumn?
- (seem mostly positive)
- BJ: Could co-host with TPAC or Khronos F2F maybe? It's southern california (Anaheim) september 23rd.
- KG: Would make sense.
- BJ: Depends on how many people also want to go to TPAC.
- KG: All things equal would be better at TPAC.
- CW: WebGPU meetings tend to be long.
- BJ: WebXR meetings took multiple days so definitely possible.
- CW: Ok let's see when the call for meetings is for TPAC.
- KG: Date for a WG (not CG) meeting?
- KG: I propose Mar27 in this meeting’s timeslot. (Two weeks from now)
- How we work as a group.
- Is this a problem for any members who currently participate in this CG? (you can also email me as one of your chairs privately: kelsey.gilbert@mozilla.com)
- KG: Mozilla would like if this group worked as a WG instead of a CG to develop a specification.
- KG: But, departure from what we do so far. Some changes. Some of us need to be added to the WG - usually not a problem. But want to verify with everyone here. Value everyone's participation. Generally, correct forum for spec development is a WG.
- KG: will also send email - any concern changing to working as a WG instead of CG?
- CW: one detail - to participate in WG, have to be in org that's a W3C member. Can also be invited experts. Spec editor, can be invited expert. Also Connor Fitzgerald, wgpu maintainer, as another example.
- KG: we did make Oguz an invited expert of the WG already, as another example. Not difficult to do so. Default's "yes" - usually the only time they say no is if you're already at a company like Google, wouldn't separately be added as an invited expert.
- KG: membership, IP considerations. Wasm's one big exception in how things work. This change would make Moz more confident in how we create specs, aligning with W3C policy.
- DM Liao: representing Figma. Was member of WebXR CG back at Oculus. Thought CG/WG difference was WG advances the specs, but CG encompasses spectators, people interested in listening in. Part of this - CGs are free to join, and WGs have a cost to join. How's this group been running / interacting with CG?
- CW: Welcome! Glad to have you here. This group's method of operation: started as CG. We have a WG; idea was that eventually the WG would stamp the spec the CG created. Similar to how Wasm operates. Here we're talking about changing this so that most of the work's done in the WG.
- KG: in terms of interaction - Github issues are public. WG has different set of guarantees than CG. Also different membership requirements. Our goal is not to be exclusive. Membership cost isn't intended to be extractive, either. End goal - get folks who want to be involved, to be involved. Today's meeting is more of an FYI; please speak up, or email me/Corentin as chairs if you have feedback. Want to know if this will dissuade anyone from participating who wants to.
- KG: Will send an email asking the whole group for comments on this transition.
- KG: If rec-track, we need to more clearly delineate what’s going into e.g. “webgpu level 1” vs subsequent specs.
- We can choose to switch to the Living Spec track, but this must be a conscious decision of the WG, because it causes rechartering. (important but easy)
- This is a CG meeting, so this is merely an FYI.
- KG: think we probably want to switch to the living spec track. It aligns better with the way our group works.
- CW: bundle that in the same email about switching to WG meetings?
- BJ: to support this idea - wish this concept had existed while doing Immersive Web work. That spec ends up with a lot of extensions - classified as "modules" in that spec. All separate individual specs modifying the base spec. Weird semantics. "This dictionary needs to be modified, but no Web IDL mechanism, so modify the base spec." Like the methodology we've been using so far. Define extensions in base spec - no confusion. Living spec supports this methodology better.
- KG: I'll email the group. Will do my homework about what the new process will look like. It's defined in the W3C policies docs, but may be hard to grok from there.
- KR: input from Apple on these?
- MW: fine with the Living Spec direction, and also fine with the WG direction.
>>>>> gd2md-html alert: inline image link here (to images/image1.png). Store image on your image server and adjust path/filename/extension if necessary.
(Back to top)(Next alert)
>>>>>
Fingers crossed the green line goes up!
“Tacit Resolution” Queue
- Nothing
createTexture does not validate viewFormats against usage #4426
- TT: revived the issue - contributor filed a bug against wgpu. When we added viewFormats to createTexture descriptor, didn't consider what happens when you create a view from that texture that doesn't support all the usages of the original texture. So when you try to bind it as a storage texture, might not be able to (e.g. in Vulkan).
- KN: tentatively closed this before, thinking there was a validation layer bug. Now do we think it's a real problem?
- TT: think that was a validation layer bug. But the one we have on wgpu is different; now it's clearer what the situation is. Could create a view with different usage, which is fine. We have to address our validation language in the spec.
- KG: can you specify usages when you create the view? (?)
- TT: no. Would be confusing if we silently remove usages.
- CW: problem is - eg.. rgba8unorm and rgba8unorm-srgb, and one supports storage and one not. Can't create BGL entry for rgba8unorm-srgb. Right now we can subset the usage and the user can't tell. Feels like storage might be the only difficult usage rn. In the future we might add usages, and the capability to use storage images without spec'ing the format in the shader. Lot of APIs support that. When that happens, I'm not sure.
- KG: good point that we probably technically don't need to do anything, but makes me uneasy. Think you'd want some indication even if it doesn't matter in the general case. If it does matter in the future, would need a solution. Rn, create texture view - inherit format from the texture, subside of usages valid for that format. Can pretend you don't know this right now because it's only the storage texture case we know of - but concerned we'll find something else.
- TT: more general soln - let people spec usage when they create the view, and make it optional. Spec nothing - take it from the texture.
- CW: IIRC in Vulkan the ability to subset the usages for a specific view is not in Vk 1.0. Don't remember when it was introduced.
- KN: requires Vulkan 1.1 or VK_KHR_maintenance2.
- CW: if in future we allow set of usages - don't want to default to the valid subset of usages. To pave way for the feature, have to add validation today. So much of a corner case that I think adding validation won't cause problems.
- BJ: if we default it to base texture's usages - what happens when you use format that doesn't support storage? Will start failing right away. (a) breaks backward compat for some small # of existing apps. and (b) feels surprising for that to happen. Could be more significant in the future. But, sort of seems we need to start doing the validation now, even if it starts introducing backward compat issues.
- KN: 2 things we could do - (a) add explicit usages to view descriptor (b) silently remove usages when creating view. Wouldn't break anything, can't do anything with it rn.
- BJ: explicit usages w/ validation would break backwards compat for a small set of cases.
- KG: does seem useful to be able to say with view, this is all I intend to do with it. Optimization opportunity for the modern APIs.
- KN: option to viewDescriptor's fine with me.
- BJ: Gregg - any impact on Compat work? Help/hinder?
- GT: don't think it impacts Compat.
- TT: think we disallow view formats in Compat. As long as usages are the same, it's OK.
- CW: options: (1) validate at createTextureView that the formats support the usage, or (2) add usage subsetting to views right now. People leaning toward (2) rn because it's a simple validation.
- General heads nodding.
- KG: I'll formally propose we move toward this.
(timebox) mapSync on Workers - and possibly on the main thread #2217
- KN: I’d like to take the temperature on this proposal. Start with taking the temperature on mapSync on workers.
- People keep asking for it, and as far as I know we've never formally asked the TAG for input on it (only relayed opinions from folks at the browsers). If there is general interest from the CG, I would like us to ask the TAG for review on a proposal defending it (many points have been raised in favor of it, and I honestly think synchronous GPU readbacks are a pretty trivial hazard).
- Only negative feedback we got on this was someone from Google not wanting worker-specific APIs.
- Think this would make a lot of people happy.
- (BTW, there's been some noise pushing for Atomics.wait on the main thread too, which I'd love to see, but it's much bigger.)
- KG: +1 to supporting this on workers.
- MW: catching up on the convo, but why do we need this, as opposed to worker waiting asynchronously?
- KN: couple reasons. Pure JS - can write logic in a way that doesn't require reentrancy. Doesn't force you to yield. Can start using it in requestAnimationFrame. Don't know whether we necessarily want to encourage this. It makes it possible to do mapping from Wasm without yielding - proposal getting standardized, JSPI (JS Promise Integration), still has a bunch of reentrancy problems. Very difficult in C++ code - these problems are major. On workers, there's no harm in allowing this.
- MW: initial input - seems fine with workers, not sure about the main thread.
- KN: great. Do we think we need to ask the TAG about mapSync on workers?
- KR: think we should.
- CW: think we should ask TAG. If they take too long to answer, can push forward.
- KG: imagine that if standards folks say OK, that's a strong enough signal.
- BJ: WebGPU wouldn't be the first API to add blocking support on workers. I have a comment on here from 2 years ago about FileSystemAccessHandle and sync operations. Think talking with
- KR: Would this enable WebGPU in AudioWorklet?
- BJ/KN: Would go a long way but other problems
- KR: Many customers that need the data back on CPU “now”.
- GT: since I write a bunch of tools to patch the API, seems impossible in workers. Wouldn't be able to block WebGPU, disable features - extension privacy issue. Can do this in main thread. If we add a feature to workers and everyone switches over to workers, tools will stop working. Talk with extension folks?
- KG: I'm with you. We should talk with folks who spec web-extensions. Not surprised, also not excited about this difficulty.
- KN: have work to do to bring this to TAG.
- CW: ok, so discussions with (1) doing this in workers (2) what happens if you do it in rAF, and block (3) etc. Think we should start a proposal doc.
- KG: welcome to put this in proposals. I'm a bit surprised you're concerned about this since we have readPixels, getImageData on 2D canvas, etc.
- BJ: think would be useful to present as much real-world data as possible. Hope group wouldn't object to browsers wanting to implement this behind a flag so we can gather some real data.
- CW / KG: do whatever you want behind a flag.
- Compat: Validating out viewFormats / view reinterpretation #4404
- KG: as long as view format matches in array, think this is the lowest overhead way forward.
- Consensus.
- Compat: validating out "2d" of more than 1 layer #4378
- GT: thought this was done in the CTS already?
- KG: approved now.
- MW: thumbs up.
- KN: Stephen said we already discussed the first of these 2 things, but not the cube map one. Make sure it's in the Compat proposal doc.
- Compat: Disallow vertex stride of 0 #4515
- GT: already a solution. Set divisor of attribute to a giant number, and it works.
- KG: instance and non-instance values?
- CW: think we have tests for both. Remember writing tests for them.
- GT: I can double-check.
- Consensus. If it works, good - don't need to disallow.
- Compat: Disallow textureLoad() of depth textures in WGSL via validation. #4512
- Discussed alternatives.
- Can do textureSample.
- CW: if anything, probably possible to emulate, but think we can validate this out for now. Emulate later if users give feedback.
- KG: seems fine if a little unsatisfying. Should probably validate it out for now.
- TT: think it's fine.
- KG: Will not block content. They can figure it out.
- Consensus: validate out for now.
- Compat: Disallow texture*() of a texture_depth_2d_array with an offset #4513
- CW: because offset doesn't work in texture 2D array shadow in OpenGL.
- CW: think emulation will be much more difficult, because offsets are designed to work around hardware precision issues. Probably can't emulate this at all.
- KG: shadow samplers aren't different types?
- CW: they're texture 2D array. I meant - the texture offset, where you offset by a number of samples - some hardware has low enough texture sampling precision that trying to emulate that won't work, and you'll have seam artifacts. Can try to find the article explaining that. Seems niche to call this builtin with an offset.
- KG: our shadow samplers are called depth?
- CW: yes.
- KN: we have comparison samplers that can only be used with depth textures.
- KG: seems reasonable then. Was concerned this would prevent 2D depth array textures from being sampled.
- TT: think it's fine. Also mentioned in a comment that texture sampler level and compare level don't exist for sampler 2D array shadow. Discuss now or later? On GLSL side, textureLod and textureLodOffset.
- https://github.com/gpuweb/gpuweb/issues/4266#issuecomment-1801992554
- KN: remember discussing this. For textureLod, think we could emulate it - don't remember how it worked.
- CW: TT could you please create a new issue for that?
- TT: yes
- Compat: Disallow bgra8unorm-srgb textures. #4514
- KG: think OK to validate these out.
- Consensus to do this.
- Compatibility mode: provoking vertex differs between OpenGL and WebGPU #4489
- CW: based on KG's proposal tweaked by KN - aside from naming, think this is what was discussed last week
- KG: would prefer these to be single enums, but if we think they should be multiple / two parts, think better than not having this behaviorally
- GT: did KN have a reason?
- KN: weakly prefer it. (1) don't leave a dead symbol “flat”. (2) (more imp't) conceptually for what we use the second arg for the other ones. Think it fits there. Like centroid/center thing. Think it's a nicer transition forward from where we are now.
- BC: what I saw there looked good. No strong opinions.
- CW: probably want to discuss this in the WGSL meeting.
Allow using a (float32-filterable 2d single level) texture view for an externalTexture binding. #4504
- KG: yes, didn't realize video codecs can give you coplanar data. Given this, this sounds fine.
- CW?: Question then, do we allow creating ExternalTexture from such a textureview, or just allow putting such textureviews in the bindgroup.
- JB: may as well just allow binding GPUTexture to an external texture in createBindGroup?
- KG: [weakly would prefer to create ExternalTextures in order to reuse semantics. We’ll discuss more]
- CW: let's discuss offline.
- No meetings next week! Moz is out, bunch of other people are too.
- KN: heads up I’m probably going to propose making a synchronous version of requestAdapterInfo
- Next is March 27
- Can be a working group meeting. Might need to restrict attendance. Will double-check things, and be doing more WG things. Living spec, etc.
- KG: any issues joining the WG, please let us know. I expect we'll have some CG meetings moving forward.
- DM: are we making a new WG?
- KN: the existing one.
- KG: The membership list is different. We'll make sure everyone's joined.
- Next agenda: