Skip to content

GPU Web 2023 10 04

Jump to bottom
Corentin Wallez edited this page Oct 10, 2023 · 1 revision

GPU Web 2023-10-04 Atlantic time

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

  • Administrivia
  • CTS Update
  • “Tacit Resolution” Queue
  • WebGPU Compatibility Mode #4266
  • 16-bit normalized texture support #3001
  • Separate read-only state for stencil and depth aspects. #3036
  • Proposal: read-write storage textures #3838
  • writeBuffer/writeTexture works with shared ArrayBufferViews but not SharedArrayBuffer #4186
  • Dual Source Blending Investigation + Feature Proposal #4283
  • Agenda for next meeting

Attendance

  • Apple
    • Mike Wyrzykowski
  • Google
    • Austin Eng
    • Corentin Wallez
    • Gregg Tavares
    • Ken Russell
    • Stephen White
  • Mozilla
    • Jim Blandy
    • Teodor Tanasoaia
  • Nvidia
    • Anders Leino
  • Deyu Tian
  • Mehmet Oguz Derin

Administrivia

  • CW: Myles stepped as co-editor of the WebGPU spec. Will do a call for editors when Kelsey is back.
  • WGSL Atlantic-time meeting next week.

CTS Update

  • GT: adding more Compat tests. Bunch of limits changed from hardcoded to calculated based on the device. Now they work in Compat/non-Compat mode.

“Tacit Resolution” Queue

  • Nothing new.

WebGPU Compatibility Mode #4266

  • CW: let's try to timebox until 12:30.
  • SW: today, want to look at texture views, or lack of them in GLES.
  • Looked at bunch of use cases and code. Decided we would really like to prefer to validate out the case where the texture view differs from the type it was created as in GL.
  • New viewDimension property on the texture is optional. Has a default algorithm for computing it if you don't specify it. Later, creating a view that doesn't match that viewDimension would be an error.
  • Gregg went through Unity, Three.js samples; turned on validation and saw what broke. Mipmap generation was the only thing that broke.
  • So, how hard would it be to write Compat-compatible mipmap generation? Gregg wrote that.
  • Impressively small. So, since we've agreed that we'll have a Compat flag, it's not too onerous to make a few small changes to make your app Compat-friendly.
  • (Alternative to this - two approaches - were texture-to-texture copies behind the scenes, or use late shader recompilation and binding of that shader to accommodate the different dimension.)
  • Thoughts?
  • CW: process-wise, I'd like to ask about agreement to land Markdown changes with changes to Compat. Markdown's fine instead of a full spec branch. Can collate things there, then land all the changes at once. The reason I propose this is that if we land Compat half-done, people might start implementing incomplete validation. Spec needs to be self-contained now.
  • JB: you mean you'll make it clear in the Markdown that these are tentative changes to the spec?
  • CW: yes. In gpuweb repo we have proposals; think we should have one for WebGPU compatibility mode. Once we feel it's ready we'll upstream everything in one PR to the spec.
  • JB: OK.
  • CW: given this, now what Stephen's suggesting, in this Markdown we'll (1) add a viewDimension optional attribute on texture creation, defaulting to (whatever). (2) add validation that views are always created with this.
  • SW: I updated the original proposal with this. Right now 6 layer textures default to cube maps, but not the same as the default for texture views. Didn't want to change too much at once.
  • Discussion about this.
  • CW: hearing bunch of silence. Do people need more information? Silent agreement? "OMG, what's happening?"
  • TT: think this is OK. Nothing more to say. :)
  • MW: I commented in the issue. Specifically, w.r.t. separate blend modes - would rather put it behind Compat mode flag.
  • CW: and in Compat mode, what do you think about the view creation restriction?
  • MW: think it'll be fine.
  • CW: great. Stephen can you start that Markdown doc and add stuff into it? Since MIke talked about independent blend modes can we have consensus on that (Teo)?
  • TT: think this would also need to be validation.
  • CW: ok, we can start with these two and keep working on other things.
  • TT: are these the two most concerning on how to do without validation?
  • SW: cube map arrays are difficult without emulation. We think that'd be the only one requiring late shader recompilation and emulation. There is an extension for cube arrays - 40% of GPUInfo reports support it. We could add a cube array specific extension for Compat.
  • CW: #4266 has the list of incompatibilities we found from looking at specs and CTS runs. First 9 points probably require validating out.
  • TT: ok. Issue description has been edited multiple times, wasn't aware of this. There's a Google doc that's been shared. Which is canonical?
  • SW: think it's best to do a Markdown proposal. The issue is the most formal proposal. There was a spreadsheet with all the different options, but I didn't update the current option. Apologies if editing in place isn't often done.
  • CW: process-wise, perhaps note in comments if a change is made. The Markdown doc should contain only those things where we've achieved consensus.
  • TT: what about read-only depth-stencil? Think this needs to be validation, can't be emulated?
  • CW: that's surprising - think we have passing tests for this in Dawn.
  • CW: for D3D11 it works, not sure about OpenGL. The Dawn test instantiation isn't set up for OpenGL for these tests. We'll come back with data.
  • TT: any easy workarounds for some of these features, rather than putting them behind validation?
  • SW: the ones we thought were easy we put behind the list of workarounds. Lot of it is using compute shaders to emulate readbacks. There are 9 or 10 that we think are not easy / not pleasant. There's another column in the spreadsheet discussing which of these are implemented in Chrome.
  • CW: we'll come back to WebGPU Compat in coming meetings.
  • TT: can we write down for future meetings which part of Compat we'll discuss in the next meeting?
  • CW: yes. SW please work with me for next week's meeting. And TT if you want to volunteer specific parts please do.

Proposal: formats-tier-1 extension #3837

  • TT: broken down into capability and formats. Extension's only needed because we want to support Adreno 500 series devices. Otherwise it'd be in Core. Decision to support Adreno 500 was ~3 years ago. If things changed since then, maybe we can drop support for that chip family and put this in core.
  • CW: we could look at the data internally. Last year, there were still new Adreno 500 devices being sold. Can remove it from any feature level we define in the future, and say it gets only core WebGPU.
  • TT: could put the extension into core later. Similar to read-write proposal.
  • CW: mostly sounds good for us. Need to look at details. Storage binding, if depends on RW storage texture tier on Metal…
  • TT: Metal splits caps into write/RW/read separately. Storage binding here refers to write-only. RW extension proposal has its own. I encourage everyone to double-check.
  • CW: double-check for sure, but what do you think of adding a whole tier of textures at once?
  • JB: the alternative being to treat each as its own extension?
  • CW: either that, or a new extension/limit system just for texture formats, opt into individual ones, query what's supported. Maybe have a query mechanism?
  • TT: this'll probably be the biggest tier we'll have. Unless we find we can bucket some of these together into "tier 2".
  • CW: would like to suggest this looks good and we study this direction.
  • TT: also API surface so you can opt into capabilities. If you add extensions for formats, would only be 10-11 extensions for formats specifically. Don't think it's that many compared to adding an API for this. Think it makes it harder for users as well. Think extension itself should have comments on what hardware you're dropping if you enable the feature. Non-normative of course.
  • JB: we have a separate doc Kai's been maintaining, what platform facilities support WebGPU facilities. Is that document a good place to put this? Correspondence doc.
  • CW: sounds good. Don't think we have a WebGPU spec editor in today's meeting.
  • CW: let's write that we'd like to explore the direction of formats-tier-1, but probably the direction we want to go. Can we request folks to look at it, double-check things for the next meeting? Think it's doable.
  • MW: I'll double-check the Metal stuff.
  • CW: back on the agenda for next week then.

Separate read-only state for stencil and depth aspects. #3036

  • CW: Brendan from Unity brought this up. They have shaders which sample depth but write to stencil. Right now in WebGPU, depth read-only has to be the same as stencil read-only. Would like to decorrelate this. Kai says in D3D12 this is supported. Believe this is supported in Metal. In Vulkan, requires KHR_maintenance_2, very old, could require this all the time and put it in Core. Need to double-check on all the APIs. Lift restriction that it can be put in Core?
  • TT: didn't find this wording in the spec. Spec indicates this should already be supported.
  • CW: See this section of the spec
  • CW: if we do enough homework we should be able to lift this.
  • TT: thanks for link. Sounds good I think for us.
  • CW: let's take homework. MW can you verify this is OK in Metal?
  • MW: yup
  • CW: we'll check Vulkan, which devices this loses, and D3D12.
  • KR: how would this impact Compat?
  • CW: if TT's concern is that OpenGL doesn't support read-only then it affects compat. But if Compat can do depth/stencil readonly for OpenGL, won't impact Compat. Let's do homework.

Proposal: read-write storage textures #3838

  • TT: where we left off last time: figuring out if we can do tier 1 and make it core. Did you check the Chrome stats?
  • CW: right, we didn't do that.
  • TT: right now, proposing three tiers. But tier 3 shouldn't be needed if you write the spec to combine tier 2 with formats-tier-1 we just talked about. Those two extensions would enable add'l formats.
  • CW: texture format tier 1 would be gated on Metal RW texture tier 2.
  • TT: yes.
  • CW: seems unfortunate because there are devices with only Metal RW texture tier 1. Can have WebGPU texture Tier 1.
  • TT: let's assume storage texture tier 1 here becomes core. No remapping. Treat it as its own thing. Left with tiers 2 and 3. Tier 3 not necessarily needed if you need Tier 2 with formats-tier-1.
  • CW: so an extension, if you have both of these?
  • TT: yes, if both are enabled, more formats are enabled for RW storage textures. Because tier 3 is also only required because of Adreno 500. Then could make things core, don't have to remove / deprecate the extension.
  • CW: could we merge tiers 2 and 3?
  • TT: that was David's proposal.
  • CW: that would sound good.
  • CW: let's try to put tier 1 from this proposal into core, and merge tiers 2 and 3 into "extended-rw-storage-texture-support"?
  • TT: so some Vk devices won't have Tier 2, will have to opt into the combined extension?
  • CW: yes, e.g. Adreno 500.
  • KR: suggest keeping the version number so we can add a new tier later if more esoteric color formats come down the road later.
  • CW: ok. We have homework to do on the Chrome stats about Metal RW texture tier "unknown".

writeBuffer/writeTexture works with shared ArrayBufferViews but not SharedArrayBuffer #4186

Dual Source Blending Investigation + Feature Proposal #4283

  • CW: From Brandon Jones at Intel, but I worked with him extensively on it so can speak to it. New enums and a new fragment output. Useful for porter-duff gradients/blending. 4 enums to blend factor. In WGSL, adds one new fragment output, name TBD, TT raised this concern. Can only have 1 color render target.
  • CW: suggestion of index builtin in WGSL to add additional blend color. TT suggested that since can be only one render target, doesn't matter that we have an index. Sounds better. Should be supported on all Metal devices, all D3D devices, and on large number of Vulkan devices.
  • CW: everybody OK to add this extension?
  • MW: thumbs up
  • CW: then either Brandon Jones at Intel or someone on Chromium side should do the PR and then we can bikeshed the names. The name of the attribute, think TT's proposal is a good step.
  • TT: @secondBlendSource? Wondering if we'll have more than 2 blend sources in the future.
  • CW: this is an old extension. If it'd been extended since then we'd have seen it.

Agenda for next meeting

  • WebGPU/Compat – specific topics to be enumerated
    • Stephen to make PR with Markdown doc discussed today
    • Stephen and others to put down Compat topics in the agenda right here
    • Stephen OpenGL depth-stencil readonly.
  • formats-tier-1
    • Folks in general should double-check capabilities in their investigations.
  • Separate read-only state for depth/stencil aspects
    • Chromium folks are volunteering to prototype and check this, both for OpenGL and the other backends
    • MW if you could double-check on Metal would be appreciated.
      • MW: can do that.
  • RW storage textures
    • Chromium folks should look at stats, understand the unknown tier we're seeing.
  • Dual-source blending
    • Think this can be done offline. Just naming, don't need to carry this forward.
  • Looking at milestones for other Milestone 1 items that aren't WGSL:
    • What about discussing #822 support for arrays of textures/bindings in general?
    • Cannot upload/download to UMA storage if anything new?
    • MW: did look at UMA stuff and discussed with Myles briefly. It's been a few months.
    • CW: I think this is an important issue, would like us to try to find a way forward, but very complex. Little by little let's try to remember and reinvestigate this. Scratch this from the agenda for now.
  • Please add more topics that come up.
  • TT: could we get a list of devices that don't support any read/write storage textures? "Tier none" from Apple?
    • We'll of course check what's out in the wild in Chrome…
    • MW: I'll double check on that.
  • Next week's meeting is Atlantic time again.
Clone this wiki locally