Minutes 2021 06 07

GPU Web 2021-06-07

Chair: Corentin

Scribe: Austin / Ken / Corentin / Kai

Location: Google Meet

Tentative agenda

• Administriva
  • What should the TAG review focus on? Context: https://github.com/w3ctag/design-reviews/issues/626
  • webgpu.org
• CTS updates
• What binding numbers are used by an external texture binding? #1721
  • Shader-visible entities occupying multiple locations #1733
  • Limit the binding number for resources #1783
• Consider merging GPUSwapChain into GPUCanvasContext #1780
• Add forceSoftware adapter option and isSoftware adapter attribute #1734
• Allow read-write storage on selected texture formats #1772
• "Sampled" is ambiguous in the spec #1785
  • Remove the read-only texture storage bindings #1794
• Reconsider the name of storeOp: "clear" #1761
• Agenda for next meeting

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Brandon Jones
  • Corentin Wallez
  • Kai Ninomiya
  • Ken Russell
  • Shrek Shao
• Microsoft
  • Damyan Pepper
  • Rafael Cintron
• Mozilla
  • Dzmitry Malyshau
  • Jeff Gilbert
• Francois Guthmann
• Mehmet Oguz Derin
• Rick Battagline

Administriva

• What should the TAG review focus on? Context: https://github.com/w3ctag/design-reviews/issues/626
  • CW: Would assume privacy/security most important. Are there other things we would like them to pay special attention to?
  • DM: Mapping?
  • KN: I think all of the API design, etc. The things in the explainers are the things we think they’d be interested in looking at.
  • CW: Okay, so we can direct to privacy, security, mapping, ..
  • KN: They have to know about object validity, destroyed, etc. Multithreading, probably. Canvas output maybe, so it’s only a couple sections that are that important.
  • MM: I think the extension model is important. I think fundamentally the fact we have extensions is different from most Web APIs. They may have opinions about that.
  • KN: I’ll check if what we have written about that is sufficient. We do have a section for it. I’ll put it in the list of things they should look at.
• webgpu.org
  • CW: University of Illinois transferred the domain for use with this group. Right now, it has been transferred to Google, but the point is that it is for the group so we can transfer it back. Any concerns with governance we’d be happy to change. We’ll have to decide who should be on the .org.
  • MM: Philosophically it seems like it should be owned by the W3C. Have you talked to them? We should at least talk to them because maybe they have a system for it.
  • CW: I will ask Francois Daoust.
  • CW: We’re still discussing the WebGPU github organization. For that to happen, we need to decide what this group wants to do with the org - move the repos there? etc. Or use it for general community vs. community/working group
  • MM: Just make sure links don’t get broken.

CTS updates

• KN: Continuing work on conformance tests. I’d just like to say the CTS is probably the most important cross-browser effort for releasing a 1.0. It’s a complex API and without the CTS we have no way of testing interoperability between browsers. It’s a top priority and we’d like to impress that it should be important for other browsers as well.
• MM: Do you have a set of tests that are committed to the repository that isn’t part of the CTS?
• CW: We have a few Chromium tests in the Chromium repo, and we have fairly good testing of Dawn in standalone. Similar to angle_end2end_tests and more focused on implementation details. Less comprehensive than the CTS.
• MM: Okay there’s an intentional distinction.
• KN: More out of practicality because it’s hard for us currently to run CTS against the native implementation. Can’t make changes to Dawn and the tests all as one patch. So partly lots of tests have gone into Dawn because it was practical to do there. There’s about 10 web tests in Chrome that are Chrome-specific that are there because they happened in the middle of prototyping. The Dawn stuff, there’s a lot of stuff that tests the behavior of the API, but they do so not-comprehensively. Much of that needs to be ported into the CTS.
• CW: Chromium is looking to an Origin Trial soon-ish, and having good CTS coverage for security and some validation is a blocking issue for the OT so there’s less interoperability risk, and obviously security issues.
• CW: wgpu is testing against the CTS, I think?
• DM: Is aiming to.
• CW: We’re putting effort into it, but also please test your browser against it and raise issues, and contribute to the core testing effort.

What binding numbers are used by an external texture binding? #1721

• Shader-visible entities occupying multiple locations #1733
• Limit the binding number for resources #1783
• DM: In principle it’s a fine idea to make a single binding for the external texture. Implementation-wise it’s blocking us from generating the SPIR-V and creating a Vulkan shader module at shader module creation time. I was looking at a way of addressing multi-binding resources. Each multi-binding thing is on its own and it seems best to just tackle them case-by-case.
  Thought about if there’s an easy workaround so we can create the shader module earlier - I think this is to limit the binding number for resources to some max value.
• MM: What was the way?
• DM: Limiting them to 16 bits.
• MM: I think that’s fine.
• RC: Is the number of ones we have to reserve depend on what you bind?
• KN: No you need to reserve the maximum because you don’t know what’s bound yet.
• JG: We’d also need to limit the max for the spec/conformance which would validate as-if you took three textures.
• RC: Is that what it means to be 16 bit?
• JG: The 16 bit is so that we allow users to specify bindings up to 16 bits, and we reserve the numbers after that for internal usage. So if the user uses binding 4, we won’t expand to 4, 5, 6, but use the higher numbers.
• MM: I think this requires that bindings be sparse. Obviously not going to make a table of 2^16 elements. If they’re sparse, why not say the app can specify values greater than 2^16 and we’ll just find a hole and put in the resources wherever we can.
• JG: I think because you don’t know what entry point your using.
• DM: Rather: you don’t know the pipeline layout, so the construction of the table would need to be static.
• MM: In Metal, you either have the hint (entrypoint hint) and you compile the shader then, or you don’t have the hint and you compile it later. Actually - in Metal I don’t think this matters. Maybe it does in SPIR-V.
• KN: The bind group layout without the shader, and the shader itself, need to pick the same holes.
• MM: Because you want to compile SPIR-V before you know the pipeline layout.
• CW: Yes. Feels like the same discussion as the MTLLibrary one.
• DM: The SPIR-V situation is simpler than the Metal situation. It’s only happening because of the magical external texture bindings.
• MM: You’re worried about the cases where the author has not supplied a PL but you want to compile anyway.
• DM: Or they supply it and it’s wrong.
• MM: Okay it’s fine. 2^16 is okay.
• JG: How would I use this limitation to do the implementation.
• CW: You’d offset by 16 bits.
• JG: So binding N takes N, N + Uint16Max, N + Uint16Max + 1
• CW: Something like that.
• JG: Didn’t someone say that Vulkan is not efficient with large sparse descriptor maps?
• CW: Yes. You don’t have to do this, could repack the bindings.
• JG: Okay, not super excited about it being workable, but if we run into problems with it then we give up the thing we were trying to do.
• CW: We implement it, but we also reorder our bind group layout, so we wouldn’t take advantage of it.
• MM: Okay so Firefox can try it out and see their mileage.
• DM: It’s not going to impact most people. Can always lift it later.
• CW: For now, take the 2^16 limitation just because we can, and maybe it’s useful, and probably doesn’t bother anyone?
  Then, Firefox looks at whether the limitation helps them. If it really doesn’t work, then we change to say the binding point takes 4 bindings.
• JG: Okay so actionably, we just take the 2^16 limit.
• RC: guess this satisfies my question. We'll leave gaps, and have 2^16?
• JG: no. Just the 2^16 limit. No gaps.
• MM: If an author wants to make an external_texture at index 4, they can also have a regular texture at index 5, and that’s okay. They can’t make a binding at index 2^16.
• RC: Okay and if we discover a performance problem, then maybe change.

Consider merging GPUSwapChain into GPUCanvasContext #1780

• BJ: Currently have both GPUCanvasContext and GPUSwapChain. The change asks if we really need both. Historically, there were ideas other APIs might want to use their own swapchain. WebXR was thinking about this, but the use case evaporated. As it stands now, it seems like unnecessary complexity to have both. Can smush them together into one object. You get it back, you get a preferred format, you get current textures, and it has a configure option which takes in the original GPUSwapChainDescriptor. Every time you want a new swap chain, you call configure(..). There’s no big issues I’ve seen in doing so. Some details about if you haven’t called configure(..) then getCurrentTexture() returns an error.
• MM: At the beginning of this, you mentioned that WebXR wouldn’t use the swapchain because it’s not flexible enough. Is that correct?
• BJ: yes, effectively. WebXR group looked into it; there are a bunch of WebXR specific needs (like allowing the system to produce a swapchain of depth/stencil textures for reprojection), returning texture arrays as the swapchain output, etc. Not appropriate to push back onto WebGPU; only need them in XR. Probably want swapchain-thing like in XR, but not instance of GpuSwapChain.
• MM: That makes sense, so if a dev wanted to use WebXR and WebGPU at the same time, they would say canvas.getXRSwapChain?
• BJ: we have different mechanism. Not tied to canvas, because output's not on page; on other device. Yes, would say: GpuBindings object, you get a layer from it, turn it into swapchain. Can discuss more later.
• MM: hope you don't have to recreate parts of the WebGPU API.
• BJ: Would be minimal. Most things to reinvent need to be XR-specific anyway. Didn’t feel to us we were reinventing too many wheels.
• MM: ok. Say you combine these objects; have you added any add'l functionality that wasn't there before?
• BJ: Not particularly. There’s a small bit of extra functionality in that you can call the configure(..) with null and effectively break the association with a particular device. I don’t know if that’s necessarily new functionality, just a way of cleaning up after yourself to be more explicit about. You can’t allow the context you get from the canvas to garbage collect itself the same way the GPUSwapChain object could.
• MM: so it's about freeing resources early. OK, sgtm.
• CW: Any other comments/concerns on this? for the details we can iterate on the PR on Github.
• DM: concern that getCurrentTexture() can suddenly give you a texture from a different device. Usability concern? Happens if 2 actors are using the same context. Not in line with the other APIs we have. But seems harmless because from user's POV it's like it's internally invalid.
• BJ: Previously, if you had the scenario of two actors fighting over the same context, you would call configureSwapChain which would have invalidated the other swap chain. In the new scenario, you will get a texture out that is valid, but for a different device. You will technically get a different validation error, but the end result will be the same (validation error).
• MM: and trying to render into texture from wrong device won't work?
• BJ: validation error either way.
• KN: maybe in spec we could call them same thing. Invalid == doesn't have device. Now it's literally identical validation.
• CW: We thought about this for impl details of Dawn and it didn’t work. Don’t remember why though.
• BJ: if you're trying to call methods on the object itself, you need to know which device the errors should be sent to.
• BJ: Best place for comments would be #1810.

Add forceSoftware adapter option and isSoftware adapter attribute #1734

• MM: Boolean is acceptable. I think this issue is ready to go. We have thoughts on other issues that we will be opening.
• CW: I was going to call out adapter.name.
• MM: I meant to say this in writing earlier, but didn’t. Sorry to delay.
• CW: anything else on this topic we should discuss as opposed to just adding the boolean? (No.)
• KN: does this mean we can land this?
• MM: yes.
• KN: great.

Allow read-write storage on selected texture formats #1772

• CW: it's not all the same formats as writing to storage textures, at least because of D3D12 (heard from DM earlier). Some D3D12 typed loads not supported on all formats. But could support RW storage for some? Biggest thing, RW storage not guaranteed to be supported on Metal, have to query on the MtlDevice as of 10.13.
• KN: yes. Prior to that, no support, but after, no commitments on support. Runtime check needed.
• CW: can we lift WebGPU support to 10.12 and devices that have this support, or not?
• MM: think this is a question for Dean. I can talk with Dean and come back in a week?
• CW: sounds great.
• CW: how about FF and Chromium look at user stats on <= macOS 10.13 and see if we can afford to lose those users.
• KN: macOS 10.13 actually. (Corrected above)
• KN: I don’t think this is something we need to decide now. We can add features to core later, and we will probably. We can say we don’t have this yet.
• MM: trying to remember public version numbers. High Sierra.
• KN: 10.13 is High Sierra.
• MM: We wouldn’t ship there. I will not ask Dean then.
• KN: we need to understand: what does Metal read/write texture tier 1 mean, and can we rely on that as well as 10.13.
• KN: if we want to put this in core then we can only support devices that have tier 1 support. If you can tell us what devices support that we can figure it out, or we can add metrics.
• MM: I think the best option forward is metrics in browsers. I think it might be challenging for me to release that information.
• KN: don't understand situation with this feature. Not tied to specific hardware. Historical accident?
• CW: If Myles cannot get the info, then we can take an AI to gather some stats on that. It will take some time.
• MM: years? months? weeks?
• CW: months.
• MM: should be within the timeline. So acceptable path forward.
• KN: only need this to add RW storage, so don't need for V1.
• CW: would be nice to have for V1.
• RC: Do you only need load/store of UAVs? on D3D you can’t do bitwise add, etc. on R32 floats.
• MM: you can load store and sample. No function to add X to this texel.
• CW: in SPIRV you can get pointer to texel.
• MM: we don't have that in WGSL because that functionality doesn't exist in Metal.
• RC: So long as it’s just load/store then it should be fine for R32 float/uint/int.

"Sampled" is ambiguous in the spec #1785

• Remove the read-only texture storage bindings #1794
  • Please all do homework on this.
  • DM: We realized that readonly storage in the way they are exposed don’t allow the users to do anything they couldn’t do otherwise with sampled. They don’t map that well to the backends. D3D and Metal don’t have anything like this. On Vulkan, we would use Storage which is made for read/write more than it is for readonly. Seems like we could get away with removing readonly storage textures.
  • MM: So if you wanted readonly, what would you do?
  • DM: Bind as a sampled texture. One of the goals here is also to make sampling concrete: you use a sampler. But you can also just read a texel without a sampler.
  • MM: so sampled textures can be both sampled and read from?
  • DM: like today, yes.
  • MM: sounds legit to me.
  • CW: would still like to think about this more.

Reconsider the name of storeOp: "clear" #1761

• KN: A long time ago we decided to call storeOp “clear” for “don’t care” “discard”, etc. However, “clear” is misleading according to developers because it sounds like it’s doing something. In reality we just put it back in the uninitialized state. Both “store” and “clear” sound like they’re doing something, so it’s unclear if it matters.
  We picked “clear” because it was explicit about the actual semantic - it appears to be cleared. But people are choosing the wrong option.
• MM: I think you’re right that the name is bad. I think the choice about what is best depends on whether we want apps to rely on clearing or not. I think we don’t want to do lazy clears. So I think the best name is “discard”. We want developers to act as if it is discarded. If it is observable what the result is, then we need to do work to fixup the texture. A valid way to think about that is something the browser needs to do for portability and shouldn’t be what the operation the dev is asking for.
• CW: note this is the third time we've discussed this exact same question. We might want to look into why we decided not to change the previous times, just to make sure.
• JG: was 23 months ago.
• (Wow. Pre-COVID!)
• CW: people mostly happy with this change. Let's just do homework, see the pre-COVID discussions and if they still apply.

Agenda for next meeting

• Nuking of read-only storage textures.
• MM: if I file an issue about GPUAdapter.name strings before Thursday deadline it can be on the agenda, otherwise not.
• HDR? ColorSpace stuff?
  • KN: Nothing new on existing WebGPU color space discussions.
  • KR: Canvas HDR being discussed. The non-HDR, wide-color gamut (WCG) changes are already figured out for WebGL and WebGPU.
• CW: getBindGroupLayout changes #1806.