Skip to content

GPU Web 2023 09 27

Jump to bottom
Kai Ninomiya edited this page Oct 11, 2023 · 2 revisions

GPU Web 2023-09-27

Note that unless stated otherwise this is a GPU for the Web community group meeting and not a working group meeting.

Chair: Corentin

Scribe: Ken

Location: Google Meet

Tentative agenda

Attendance

  • Apple
    • Mike Wyrzykowski
  • Google
    • Corentin Wallez
    • Gregg Tavares
    • Ken Russell
    • Loko Kung
    • Shannon Woods
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Jim Blandy
    • Kelsey Gilbert
    • Teodor Tanasoaia
  • Nvidia
    • Anders Leino
  • Jeremy Sachs
  • Mehmet Oguz Derin

Administrivia

  • What about the HDR out of band meeting?
    • KG: no meeting yet. Scheduling conflicts.

CTS Update

  • Boatload of f16 tests.
  • Lots of numeric precision tests. Not sure whether they've found driver bugs yet.
  • Compat tests. Gregg making all the tests handle Compat's different limits from core WebGPU. There were a lot of hardcoded constants - about 32 tests. About ⅔ done.

“Tacit Resolution” Queue

API Milestone 1 triaging

  • CW: looking at Milestone 1. Pushing things off to Milestone 2. Then iterate over Milestone 2.
  • SW: what's the semantic? Is M1 a cleanup release and M2 a feature release?
  • KG: yes, pretty much. In my head, M1 is the things we want to get into "V1" - for Firefox's initial release. But Chromium already shipped a V1. Some differences of opinion. M1 is things we want to treat as though we needed to do them already.
  • SW: sounds good, similar things, we can handwave. Not trying to add crazy new features in V1. Helps improve communication around this easier.
  • CW: only crazy new feature in M1 is read-write storage textures.
  • KR: what about dual-source blending?
  • CW: that's a tiny feature. Let's get to triaging. Focusing only on API things. There are ~10 issues for WGSL.
  • Dual-source blending
    • CW: Something we volunteered. Not regression compared to WebGL. 3 enums, one WGSL annotation. Useful for implementing Porter-Duff blend modes. Optional feature.
    • MW: just need some time to review.
    • TT: one concern about the naming of the index.
    • CW: to be discussed later. Pretty sure we'll go with your proposal.
  • #4277 requiredLimits must be an ordinary JS object
    • KG: fine though.
    • CW: something we want to fix in the short term.
    • KG: think this is a bug in the bindings generation and not a bug in the spec.
    • CW: Kai says in the investigation that this is at the Web IDL level…guess that needs more review. Should stay in M1.
  • rgb10a2 vertex format #4275
    • Consensus to do this.
  • Investigation: Render to 3D texture #4251
    • Already doing this.
  • Clarify usage of GPUShaderModuleCompilationHint #4222
    • KG: editorial.
    • CW: "M0" because it's editorial.
  • writeBuffer/writeTexture works with shared ArrayBufferViews but not SharedArrayBuffer #4186
    • KG: this is a bug. Put on the agenda for next meeting.
  • depthWriteEnabled and depthCompare are required even for stencil-only formats #3905
    • CW: stays in M1.
  • Proposal: rw-storage-texture-tier-X extensions #3838
    • Allow read-write storage on selected texture formats #1772
    • KG: my understanding - we should rename this so it's clear it's proposing RW storage textures, period.
    • JB: there's a separate issue. #1772 proposes RW storage textures. Mentions we'll need to talk about supported formats. This is the issue following up on that, breaking down which formats will work. Makes more sense for #1772 to have the place of honor here? This one is the details for the other.
    • KG: think we should just pivot #3838 to subsume #1772.
    • JB: yes, there's been important discussion on #3838.
  • support blending 32 bit float textures #3556
    • KR: easy optional feature, regression compared to WebGL2 extension, Unity's asked for it.
    • KG: sounds good.
    • CW: optional feature, sounds good.
  • Separate read-only state for stencil and depth aspects. #3036
    • CW: currently, both read-only or read-write.
    • KG: leave in M1 but talk about it later.
    • CW: yes, maybe something in Vulkan that makes this more difficult.
    • KG: almost anything on this list that doesn't have an active resolution should be on the agenda for the next meeting.
  • 16-bit normalized texture support #3001
    • KG: I prefer M2 for this. Not a regression compared to WebGL. Don't think it's particularly hard but we have other things to do.
    • CW: sounds OK. Using it internally for Graphite, Skia's new backend, but that's internal. Jasper clamoring for it, but that's all.
  • Expose optional texture capabilities in WebGPU #2630
    • CW: lot of requests to add certain capabilities to various texture formats. Would like to discuss earlier rather than later how to combine all of these.
    • KG: would like to defer this to M2. Unnecessary today.
    • KR: Even WebGL has the ability to ask questions about the internal formats of textures. If we could add at least an enum then it would be a good start.
    • KG: OK to leave it in M1, but then should discuss it actively. Let's add to the agenda.
    • CW: If Google can't come up with a proposal, we'll push to M2.
  • Cannot upload/download to UMA storage buffer without an unnecessary copy and unnecessary memory use #2388
    • KG: M2 please.
    • CW: we're fine if it's M2, but really needs to be in M2 then. Need to brainstorm ideas with folks in this group, maybe out-of-band. Difficult topic.
    • GT: OK with M2, thought Apple was going to do a prototype?
    • MW: OK with M2, I'll follow up.
  • Dealing with holes in the pipeline layout. #2043
    • CW: right now, hole in pipeline layout needs empty BindGroupLayout and need to bind an empty BindGroup. Wart, should fix.
    • KG: would prefer to ditch to M2.
    • CW: fine with me.
  • Support for arrays of textures #822
    • CW: and in general arrays of bindings. Can do in WebGL?
    • KR: WebGL 1 and 2 do support this.
    • KG: nobody begging for this, sounds like work, I prefer M2.
    • CW: really want to keep this in M2.
    • KR: it is a regression compared to WebGL. Arrays of textures are useful. I'll add a sample to the issue.
  • Support "uniform texel buffer" and "storage texel buffer" ? #162
    • CW: reinterpret-cast buffer as 1D array texture. Useful because it allows sampling at ??? boundaries that you can't do with storage buffers. We have internal examples making ML and other workloads faster.
    • KG: not regression compared to WebGL.
    • KR: true. But we have multiple requests from partners - one unnamed, Unity, and internal ones.
    • KG: we're trying to ship anything - more requests we have, longer it'll take us to ship.
    • CW: we're OK with M2. Gives us more time to prototype, will come back with impl feedback.

API Milestone 2 triaging

  • Mainly discussing whether to pull any of these into M1.
    • CW: on Chromium side we're trying to focus our prototyping efforts.
  • Raise maxVertexBuffers default to 16 #4284
    • CW: before Metal 2, need the current spec limit. But it could be lifted.
    • KG: my understanding is that Apple isn't concerned about this. If wgpu supports this, neither does Mozilla.
    • TT: no arg buffers yet. Someone's interested in working on them.
    • KG: wgpu on Metal doesn't arguments buffers yet so M2 is good.
  • Extended brightness range rendering #4239
    • KG: priority-wise, think HDR rendering comes after other things for M2. So I'd push to M3. But that's my gut feeling, I'm pessimistic. Shouldn't be in M1.
    • KR: Browsers already support HDR for core media (like for Netflix and friends) would like to visit this in Milestone 2 and not push this further. The spec changes are small compared to the gains.
    • KG: OK. I would draw a line between Netflix's HDR video, and other HDR stuff in the browser. All of FF's work is for HDR video, not anything else.
  • add mirror-clamp-to-edge filtering #4215
    • KG: no concerns about doing this in M2
  • API should be exposed to ServiceWorker #4197
    • KG: M2 sounds great.
  • Image uploading is insufficiently expressive to be optimized #4185
    • KG: M2.
    • CW: definitely not M1. If we don't find a good way to handle this, can push back from M2.
  • Ordering of promises when device is lost #4177
    • Minor issue.
    • KG: we looked into device loss recently. A little weird. Can leave in M2, and move if needed.
    • CW: do you think this should be in M1?
    • KG: not really. If we do this in FF for M1 we could make the spec more readable.
    • CW: that sounds good.
    • JB: I'd like the most to get clear language in the spec, and the CTS exercising it ASAP.
    • CW: let's move it to M1 then.
  • Copying depth32float to depth32float #4125
    • KG: mark editorial, needs-CTS.
    • CW: let's put it back in M1. Needs discussion, not sure it's just editorial/CTS.
  • Validation and behavior of alpha-to-coverage #3982
    • CW: loosen some validation in v1. Not very urgent. Can keep in M2.
    • KG: OK.
  • Considerations for subgroups #3950
    • KG: M2 is great.
    • CW: M1's too early, lot of investigation to be done. This is a must-have for Google in M2.
  • Proposal: formats-tier-1 extension #3837
    • KR: have a request from Unity for some of these in RW storage textures. M2 is fine.
    • CW: OK, leave in M2.
  • Dealing with holes in the pipeline layout. #2043
    • CD: Keep it in M2
  • Resurrect clamp-to-border #1305
    • KR: Ran into a ton of driver bugs with this functionality recently, not sure if fixed in Vulkan. Massive GPU memory corruption bugs, were horrible to track down. Push to M3?
    • CW: let's push it out to M3.
  • Allow writeTexture into depth textures? #1043
    • M2
  • Support for attach-less render passes #503
    • M2
  • HW Clip Planes support #390
    • M2
    • KG: there are WebGL extensions adding this recently, but not a practical regression compared to WebGL.
  • Viewport rect must lie entirely within the current attachment size? #373
    • CW: APIs allow this, minor bug, I suggest M2.
    • KG: this should be closed. I think this was originally, should we have validation that requires it? We added this. Now, we're asking if we should remove that validation. Should be a new bug, and it should be M2.
  • Investigation : Push Constants #75
    • KG: M2.
    • JB: don't function overrideable constants handle this?
    • CW: no. It's small high-frequency overrides.
    • JB: doesn't the API have other ways of getting the same effect, just as good?
    • CW: not with the same performance.
    • KG: if uniform updates aren't fast enough for you to update your MV matrix, you do this.

Render to 3D texture https://github.com/gpuweb/gpuweb/issues/4251

  • CW: prev meeting, feedback was we should be able to render to multiple 3D depth slices at once. (Not the same slice multiple times in the same render pass.) Implementing, D3D12 debug layers complaining. Bug in the D3D debug layers - should work. Suggestion is to move forward with this - there's a PR. https://github.com/gpuweb/gpuweb/pull/4254
  • CW: adds depth slice member to the render pass color attachment dictionary, defaults to 0. (Maybe shouldn't default?) Then can render to that slice. Can render to multiple slices of the same mip level.
  • Agreed it should be required to specify the 3D slice if you have a 3D texture.
  • CW: leave to spec editors and Hao to iterate on the PR.
  • KR: how do we know whether to run the CTS test?
  • CW: validation error if you try to run the test on an older browser, and the test fails. Fine-ish because it's detectable. Should be implemented in all browsers by the time WebGPU ships everywhere.

rgb10a2 vertex format #4275

  • KG: just a naming question.
  • PR: https://github.com/gpuweb/gpuweb/pull/4288
  • CW: couple suggestions for the name.
    • unorm10x3-2
    • unorm10-10-10-2
    • unorm1010102
    • unorm10x3-unorm2?
  • CW/KR like unorm10-10-10-2, it's more readable
  • KG: faster to say than to write, which is good!
  • CW: not putting ourselves in a corner; vertex formats aren't being added.
  • Consensus on unorm10-10-10-2.

Agenda for next meeting

Clone this wiki locally