Minutes 2021 10 18

GPU Web 2021-10-18

Chair: Corentin

Scribe: Ken

Location: Google Meet

Tentative agenda

• Administrivia
  • "Austin samples" in gpuweb org?
• CTS updates
• Milestone triage (timebox 15m) #2073
• Consider removing GPUCommandBuffer.executionTime #2156
• Remove COPY buffer usages #2172
• texture_2d_depth for loading depth values might be unnecessary? #2094
• Proposal: Add a usage bit to allow creating a view with different format when creating a texture #168
• (no proposals, skip?) Consider making ShaderModule compilation errors special #2119
• (no offline progress?) Refactor API for load/store OP and read-only attachments #2131
• Agenda for next meeting

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Austin Eng
  • Ben Clayton
  • Corentin Wallez
  • Gregg Tavares
  • Ken Russell
• Microsoft
  • Damyan Pepper
  • Rafael Cintron
• Mozilla
  • Dzmitry Malyshau
  • Jeff Gilbert
• Francois Guthmann
• Mehmet Oguz Derin

Administrivia

• CW: VF2F next month?
• CW: Will send a poll next to choose the week next month.
• Austin's WebGPU samples
  • MM: will Austin maintain them?
  • AE: I can do some work to maintain them...hoping the community will help maintain them too.
  • MM: we should have a better story than community maintenance.
  • JG: these are canonical examples...think the CG should consider adopting them.
  • CW: look at the samples and give your feedback - too big, too small? - and let's see about .
  • MM: if we're going to accept the samples I think we need criteria for acceptance.
  • JG: do you want formal criteria or a vote?
  • MM: I just don't think "Austin wrote them" is sufficient criteria.
  • JG: I think it should be the same criteria as other commits to the repo - if there's consensus.
  • CW: please look at the
  • MOD: if we accept that will we purge the samples in the gpuweb repo? Think it will be cleaner.
  • CW: some concerns with that - the samples use additional stuff to try to build a web page that's more than a single HTML file. This could also be feedback to the CG that these need to be simple JS examples.
  • JG: I'd prefer that. 2 types of samples in my mind - demos, look at this cool thing. THose can be wherever - don't think we need them as much. Think we need pedagogical examples, here's how I did this thing, and want people to be able to do "view-source". That's the split in my mind.
  • CW: AI: please take a look, we'll gather feedback.
• CW: please remember to fill out the poll for meeting times. Only ~7 answers, feels small.

CTS updates

• CW: some updates on corner cases.
• CW: big thing: we're starting to see a lot of contributions from Ben & Sarah & other folks on Tint team - testing the builtins. Starting to be a bunch of these.
• BC: Sarah's written a tool that scans the spec and finds things that need testing. ~300-400 things on the WGSL side it's highlighted as needing tests. Stubbed them and checked them in. For this next quarter to end-of-year, Tint team will be trying to flesh out WGSL CTS.

Milestone triage (timebox 15m) #2073

• #224 semantics of packed formats
  • Needs-Specification. Keep this?
• CW: did we resolve the endianness issue?
  • MM: don't think so. Needs-discussion.
  • #234 then.
• We stopped at #323.
• #354 - multi-worker.
  • Agreed you can create GPUDevice on multiple workers.
  • MM: I think this is important, we should consider it for the first release, but I can't sign up to work on it.
  • CW: on Chromium side it's something we'd like to have. It would delay V1 a lot if we had to implement this.
  • MM: maybe don't have it in V1, but make sure what we do doesn't conflict with potentially doing this in the future.
  • CW: makes sense. Some difficulty - any global state, esp. on the content process side. Buffer mapping is a big one. Need to make sure it works with multi-worker.
  • JG: agree so far. Want to look at this but not signing up to put a proposal together.
  • CW: OK, let's double check we aren't painting ourselves into a corner, but probably delayed after V1.
  • JG: think we should figure out roughly what this will look like by V1, but not implement it after V1.
  • MM: ok, so split it - small piece before V1, larger (implementing it) after V1.
  • CW: sounds good.
• #373 viewport rect must lie entirely within the attachment size
  • CW: constraint from Metal.
  • CW: Myles got the docs fixed - not actually a constraint. Revisit for V1?
  • JG: sounds easy, sure.
  • CW: Vulkan still has constraints. Viewport can't be more than one attachment size away from the viewport. (?)
  • MM: think this should be in V1.
• #386 mipmap generation
  • MM: too late. We should have this, but too late. Not for V1.
  • CW: think we agree with this. Post-V1 then.
• #405 can you put "none" for visibility attribute in GPUBindGroupLayoutBinding?
  • MM: sounds like a good idea.
  • JG: seems fine.
  • CW: allowing "none"?
  • MM: impl in browser seems straightforward. If it can help web authors write simpler code, fewer branches, sounds good to me.
• #425 uniform buffer block size issue on Metal
  • CW: WGSL question. In Metal, size of some structures will be aligned to largest alignment. In this case, block structure with vec4 structure, entire block aligned to 16 bytes, so 32 instead of 20. Need to be consistent on all backends, so min-buffer-size validation is correct on all browsers and platforms. What's the rule in WGSL?
  • BC: no, the spec's lacking. There are requirements on alignment of uniform buffer, but no requirement on min-size of buffer. That's where this gets tricky.
  • MM: knowing sizes of types is a requirement for the first release.
  • BC: size is well defined, but not strong definition of min-size of uniform buffer.
  • CW: this is the API side - reflects info from WGSL, says binding has to be min this size. Reflected size of block - aligned to their alignment - so this issue is basically fixed.
  • JG: that sounds right. That's the resolution. Not sure if we do it right now.
  • MM: should be V1, Needs-Spec.
• #426 clarify buffer usage validation rules
  • MM: think we should do this post-V1. Needed to make 3 copies of each buffer, one to get uploaded, one to operate on, and one to download from - sucks, but think it's OK for V1.
  • CW: resizable BAR…
  • JG: all APIs have a little bit of this. 100's of megabytes, rather than gigabytes.
  • CW: let's make sure we keep this in mind - we will do so from Google's side because of thinking of integrated GPUs.
  • MM: probably a way to do this without relaxing portability constraints.
  • CW: think so.
• #471 add spec text for "navigator" and "navigator.gpu"
  • CW: done, closed.

Consider removing GPUCommandBuffer.executionTime #2156

• CW: on one side, there's no way to measure time on iOS devices. On the other hand, measuring time doesn't mean anything on some Vulkan devices.
• MM: things in core need to be present on all WebGPU devices, ~all of our target devices. If no way for some of our target devices to get any timestamp at all, think this has to be optional. Since we already have an optional feature more powerful than this one, think the utility of 2 optional features doesn't make sense - so I'm OK with this, surprisingly.
• CW: makes sense, thank you.
• CW: eventually - would like to see for mipmaps or this, a way to have a library blessed by the group, here are some helpers for useful things.
• MS: execution time was suggested as being core when we talked about timestamp query. Big idea, removing timestamp query was partially based on this being core.
• MM: I have a PR for adding timestamp query back as an optional feature, not in core.
• JG: wasn't the problem that we couldn't support timestamps everywhere?
• CW: we can support them in passes on Metal.
• MM: lot of different issues. Execution time as available on the CPU - that's one issue. Fidelity of the optional feature of timestamp queries - distinct. PR I made changes the fidelity of the timestamp queries per our previous resolution. As half-step, in middle of timestamp query discussion - had resolution to remove the optional feature from the spec. Seems to not have happened. Don't think anything's getting removed though group resolved to do so temporarily.
• CW: think we decided to leave it place until …
• JG: where are we? Where are the linked issues, where did the discussion take place?
• CW: discussion about removing timestamps in passes was issue that timestamp queries are unimplementable on TBDR.
• MM: #2 changing granularity of timestamp queries.
• JG: 2046, have PR for 2190, … what does this PR do?
• MM: this PR doesn't remove the timestamp query feature. Only changes the granularity with which you can query the results. Just reformulated.
• CW: group agreed on the approach on the PR. Editors can comment since we agreed to the structure of it.
• MM: concern was: a few weeks ago this group said, we'll remove the optional timestamp feature. Then we do so, we have nothing. But this doesn't remove timestamp queries, it just reformulates them.
• JG: the ones that aren't implementable on Androdi?
• MM: no. The Android phones that have no timestamps at all won't get this feature. Metal will, so will desktop GPUs.
• MS: available everywhere that executionTime would have been?
• MM: no, older iOS devices that would not have been able to support the timestamp query optional feature. On those, no timing info at all. If there are Android devices that can't get any timestamps then nothing can be in core.
• JG: if they can get no time information, sure.
• CW: yes. Vulkan doesn't have any timestamp bits of precision.
• JG: on these devices, is there any way native developers use to time things?
• KR: on the OpenGL ES / Android side of things, elapsed time queries were definitely supported, where global timestamps were not.
• CW: think Vulkan is a functionality regression compared to OpenGL ES. I'll investigate.
• CW: say anything about granularity of timestamps? Force quantization?
• MM: won't answer that question - Apple will confer internally. Say no for now, then we'll open an issue.

Remove COPY buffer usages #2172

• CW: in some places, you can't do this thing because you have the wrong usages.
• DM: Concerns about this, because it's not 100% transparent and all buffers can do copies. But right now you need to look at the MAP flag to know. So think they should specify.
• CW: in some cases, buffers aren't copy_src or dest because they're mappable. Not transparent removal. If we allow all buffers, including mappable ones, to be copy_src or dest, would be more palatable. Completely transparent.
• CW: I'm happy to take an AI to see what it'd imply to have mappable buffers also be copyable - map_read being copy_src, and map_write also being copy_dest.
• JG: do you have that the other way around? Think that's what we have now.
• CW: maybe. :) I'll look. Upload / readback heaps on D3D12 in particular. Mappable buffers that are read/write and copy dest/src?
• RC: you can, but not as efficient as having them opaque to you. Also works only on certain hardware.
• DM: it's a complex topic about mapping and what we can/cannot do. Spent thousands of hours discussing. Using copy usages to resurrect topic. Would push us back from shipping for ~1 year. Would rather we ship with the usages and then investigate post-V1.
• MM: I do plan on investigating this. Maybe we should defer this and discuss it and the larger investigation later. Post-MVP?
• CW: happy to revisit if you have a larger investigation / proposal for V1. Hopefully it doesn't change all of buffer mapping.
• CW: what does the group feel about texture copy usages? Usual constraint, you can't copy into depth texture from buffer, etc. Mostly orthogonal, constraints are already there.
• DM: are we sure there's no cost?
• MM: think other people in the group have intuited there's no cost.
• CW: I can check open-source Vulkan drivers.
• DM: is it also explicit on D3D12?
• CW: no, it's implicit.
• DM: let's check the drivers and come back to this.
• CW: an action item on my side again. Probably not for next week.

texture_2d_depth for loading depth values might be unnecessary? #2094

• CW: just a check. MM do you have data?
• MM: we're comfortable with this change. For now. Because WGSL textures are less expressive than Metal textures. No gather(). As we add functionality we'll either need to add limits or make sure WGSL texture functionality works for both.
• DM: it can constrain us later? Concerning.
• MM: it might constrain us. By acceptin this change we're accepting additional impl requirements.
• DM: maybe we can at least have the first line of concerns checked - gather(), etc., and make sure those are compatible.
• CW: probably possible to emulate gather() via shader code. Bad, but could work.
• MM: you don't want an if-statement around each texture op. If you do, that's objectionable.
• CW: let's defer, but can you make a list of things Metal textures can do that aren't in WGSL yet?
• MM: yes. That's just comparing header files.
• CW: thank you. Let's check before making a final decision.

Proposal: Add a usage bit to allow creating a view with different format when creating a texture #168

• CW: discussed this last week, needed more work.
• CW: there's a list of format conversions / reinterpretations available on all APIs. In particular RGB/sRGB. People wouldn't be able to do stuff if we didn't have it. OK to have bits for reinterpreting the format?
• MM: this is the least expressive reinterpretation. sRGB/RGB.
• CW: we'd allow whatever's green on all the APIs. We found a bunch of reinterpretations that are allowed.
• MM: and if no bits are set, no reinterpretation allowed.
• CW: yes. Some Intel hardware has high cost for RGB/sRGB reinterpretation.
• MM: as long as it's the rough intersection, OK.
• DM: hwo about spec'ing list of formats during texture creation where they want to see it? If on D3D12, it's free. User knows what they want to reinterpret as ahead of time.
• MM: any native API do it that way?
• DM: Vulkan.
• CW: it's core now.
• DM: just not in Vulkan 1.0.
• CW: it's in 1.2.
• MM: think we're targeting 1.1.
• CW: 1.0 + extensions, or 1.1
• DM: it's that a lot of machines have that Vulkan and we can use that API.
• CW: adding that bit … Metal has some free conversions too.
• MM: think it's a pain for developers having this big list.
• JG: yes and no. I find it annoying if you set a bit, then have to lookup in a table what I can do. Passing a list is easier. Exception: you're creating the resource, don't know how it'll be used. E.g., let me use the max set of things I can use. Long list. You should probably make a big constant if you reuse this a lot of times.
• JG: I do like an a la carte approach - if you don't need the overhead you don't get it.
• RC: in D3D12 sometimes things are fully castable, and not. Specific API you have to call to find out whether something's supported, and a table predicting what the API will return.
• CW: in WebGPU I expect one table, these reinterpretations are allowed, these aren't. The intersection among all APIs.
• RC: if you want reinterpretation, do you say this is what I want reinterpreted?
• CW: you'll have to say something as a developer. Do you say, I want it reinterpreted but don't say how, or these are the reinterpretations I want?
• MM: q about yellow cells.
• RC: D3D has CheckFormatSupport. Yes/No, you can reinterpret this. In spec, Excel spreadsheet and MSDN, tells you what that API will return in case the spec requires it to be supported. Yellow, says "optional", have to check. Others, should still check, but predits what the API should return.
• MM: if box is yellow, developer checks, gets "no" answer - what should they do in response?
• RC: use a different format.
• MM: so you keep checking formats until it returns yes.
• RC: yes.
• MM: interesting, food for thought.
• CW: in future release will have to figure out optionals for these formats.

(no proposals, skip?) Consider making ShaderModule compilation errors special #2119

(no offline progress?) Refactor API for load/store OP and read-only attachments #2131

Agenda for next meeting

• KR: migrating Austin's samples to the main GPUWeb repo.
• reinterpretation of texture formats. MM should have feedback by then
• MM: can do homework on depth texture types in Metal
• CW: Will do homework for copy usages for textures
• CW: Will do homework for timestamp.
• CW: GPUAdapter.name.
• KR: would like us to make progress on #2119, ShaderModule compilation errors.
  • CW: OK, non-stretch topic for next week.