Skip to content

GPU Web 2022 01 19

Jump to bottom
Kelsey Gilbert edited this page Jan 22, 2022 · 1 revision

GPU Web 2022-01-19

Chair: KG

Scribe: Ken, others

Location: Google Meet

Tentative agenda

  • CTS Update
  • “Tacit Resolution” Queue
  • Triage the issues without milestones (timebox 15m).
  • APAC member driven discussions
    • Swapchain formats (sRGB and Float16) #1231
  • GPUAdapter.name considered harmful #2191 (timebox 20m)
  • (stretch) (again) Proposal: Add a usage bit to allow creating a view with different format when creating a texture #168
  • Agenda for next meeting

Attendance

WIP, it is the list of all the people invited to the meeting. In bold the people that have been seen in the meeting:

  • Apple
    • Dean Jackson
    • Myles C. Maxfield
    • Robin Morisset
  • Google
    • Austin Eng
    • Ben Clayton
    • Brandon Jones
    • Corentin Wallez
    • David Neto
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
    • Loko Kung
    • Shannon Woods
    • Shrek Shao
    • Ryan Harrisson
  • Intel
    • Brandon Jones
    • Bryan Bernhart
    • Hao Li
    • Jiajia Qin
    • Jiawei Shao
    • Jie Chen
    • Shaobo Yan
    • Yang Gu
    • Yunchao He
    • Zhaoming Jiang
  • Kings Distributed Systems
    • Daniel Desjardins
    • Hamada Gasmallah
    • Wes Garland
  • Microsoft
    • Jesse Natalie
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jim Blandy
    • Kelsey Gilbert
  • Oppo
    • Todd Kosloff
  • Andrew Varga
  • Brendan Duncan
  • Connor Fitzgerald
  • Eduardo H.P. Souza
  • Francois Daoust
  • Francois Guthmann
  • Jeremy Sachs
  • Joshua Groves
  • Matijs Toonen
  • Mehmet Oguz Derin
  • Nathan Johnson
  • Pelle Johnsen
  • Rick Battagline
  • Rob Conde
  • Timo de Kort

Minutes

Announcements

  • Trying to nail down a date for combined WebGPU / WGSL virtual F2F in early February
    • Don't have a firm date yet. Working on it.
    • First week of February is Chinese New Year - a no-go
    • Aiming for second week of February
    • Kelsey will send out a Doodle
    • Happy to work around peoples' schedules for other meetings
  • Kai sent out gpuinfo.org query - interesting for understanding device limitations

CTS Update

  • KN: Available tasks are on https://github.com/orgs/gpuweb/projects/3
  • KN: I’ve flushed the “Needs CTS Issue” column from the spec tracker. The necessary test changes for those are now tracked.
  • KN: if anyone has an opportunity, please check it out and contribute. I'm happy to help you get started.
  • KG: this is part of the work we have to do together - let's all contribute.

“Tacit Resolution” Queue

  • KN: Comment now or on GitHub by the end of this week, otherwise editors will land the change.
    • KN: Didn’t have an editors’ meeting this week but these are changes the editors already agreed on.
  • #2496 Change GPUObjectBase.label: nullable -> union-with-undefined, to match the input API (GPUObjectDescriptorBase.label), which is optional and therefore allows string or undefined (but not null).
  • #2464 pass command or endPass after pass has ended: make top-level encoder invalid (error on finish) -> generate validation error.
  • #2387 (comment) Depth/stencil load/store ops required -> disallowed when their corresponding component doesn’t exist.
    • Breaking change, but small API change, and API will make a lot more sense.
  • #2386 Change required (GPULoadOp or GPUColor) loadValue -> optional GPUColor clearValue + required GPULoadOp loadOp, and same for depth/stencil. clearValue gets a default value, making it easier to use loadOp:“clear” without thinking about a value to use.
    • Again breaking change, but very small.
    • Have seen a lot of people using loadOp:"load" just because it's harder to type a clear color.
  • If you need time to review these, please take your time to do it offline. Won't be doing anything with them immediately.

Triage the issues without milestones (timebox 15m).

  • #1907 draw time validation
    • KG: when do we want this implemented by?
    • MM: what are the exit criteria?
    • KN: it's essentially - can we move any of these out of draw time validation?
      • Which are expensive enough that we want to?
      • Probably could come up with a way to do this post-V1. Come up with new API for specifying things ahead of time.
    • KG: think we should mark this as post-V1, and if someone feels strongly, we can revisit it.
    • KN: agree we've probably talked about these enough that we're happy with them
    • MM: if anyone wants to move specific items, think they can do that - but for this specific one, nothing actionable in this timeframe.
  • #1925 DX12 impl friction
    • Closed last year, reopened.
    • KG: marking post-V1.
    • MM: wish these were Wiki articles rather than issues.
  • #2196 removing copy texture usages
    • KG: I removed these - why?
    • MM: we thought copy usages were free, so could be applied to every buffer and remove it from API surface.
    • MM: are we trying to determine whether this is possible for V1.
    • KG: would be stranger if we needed them after we removed them.
    • MM: I'm saying we should determine result of this issue pre-V1.
  • #2236 shader compilation time
    • JQ: can currently get shader compilation time using browser specific tools. Not that high priority for us.
    • MM: is it not high priority, or is it completely resolved?
    • JQ: we have a method to get the time. So it depends on whether you want to expose an API for developers.
    • KG: sounds like this is closed as far as you're concerned. If someone else wants to do it they can reopen it.
  • #2237 who can contribute to README.md?
    • KG: we can figure this out for V1.

APAC member driven discussions

Proposal on FP16 #2512

  • Skip this as we have already discussed it in the WGSL meeting?
  • MM: we have some updates but they're shading language specific. Next WGSL call.

Swapchain formats (sRGB and Float16) #1231

  • Current formats in Spec: brga8unorm, rgba8unorm, brga8unorm-srgb, rgba8unorm-srgb
    • “-srgb” formats are not needed?
    • Add rgba16float for HDR? What about rgb10a2unorm?
  • JC: don't need the sRGB formats?
  • KN: blocked on the view formats discussion. Don't need the formats here if you can view non-sRGB formats as sRGB when you render them.
    • I'm confident we can, just don't know the API surface yet.
    • In the PR I removed the sRGB format from swapchain formats because I don't think they're needed any more.
  • JC: Only have 2 formats needed then.
  • In Chrome, bgra8unorm format's only supported ont.
  • rgba8unorm is needed - directly writable in compute shader. Trying to lift restrictions on support of this format.
  • KN: Chrome bug. Red/Blue flip on some platforms. We just need to implement it.
  • JC: viz supported rgba16float.
  • KN: we do want this format. HDR itself's blocked on canvas figuring it out. We still want these formats even without HDR because you can use them for wide-color gamut which is well understood now. Think we should just addd it - maybe both formats.
  • KN: if we had both of these - how would browser tell you which is better on a given OS? haven't figured that out. Have a large comment in there that suggests answers.
  • JC: assumed we want rgba16float and rgb10a2unorm?
  • KN: will probably want both of them, even for SDR wide color gamut.
  • MM: when you say add this or add them, what are we considering adding them to?
  • KN: list of allowed canvas configuration formats. There are 4 now, we're removing the sRGB formats so there'll be 2 left, and then considering adding more.
  • MM: official name of that enum?
  • KN: “supported context formats”. https://www.w3.org/TR/webgpu/#supported-context-formats
  • KN: probably someone just needs to add these formats to the list. Can discuss more in that proposal.
  • KG: if someone could write the proposal that'd be great.

GPUAdapter.name considered harmful #2191 (timebox 20m)

  • (And discuss Brandon's proposal in Exposing GPU hardware information to web developers in WebGPU #2195)
  • BJ: we have the #2191 post, going over reasons why Apple didn't want to expose GPU name, but more generally identifying info for the GPU. Other issue linked here is proposals for how we could expose GPU info in a more user friendly way, and less immediately fingerprintable way.
  • BJ: for the group right now, I think over the course of these discussions we've expressed pretty well the reason for this information. So whether we expose any information at all about the GPU is probably well discussed. I think we could close #2191 and focus on concrete proposals. For people concerned about fingerprinting (everybody?), focus on exposing the info in a way as user centric / privacy preserving as possible.
  • MM: I don't think we should close #2191. Reason: I don't understand why we have 2 issues in the first place. 1 discussion with 2 issues. Closing half of the issues doesn't make sense either.
  • MM: we have relaxed a little bit since last discussion. Previously position I described is that we should not expose this for initial version, but wait for devs to tell us they need it in WebGPU. Now we're willing to have this discussion before V1 ships, but only if TAG / PING (ideally those two, but not necessarily specifically them) are involved.
  • MM: one option - there's a spectrum - one result is, no browser exposes any information. That's one end of the spectrum, but it is on the spectrum. We shouldn't close out any concern until we've consulted with experts.
  • KG: what forum would that be in?
  • MM: historically - held in joint meetings. Two groups will join the same call. Doesn't have to be that way.
  • KG: this sounds reasonable to me. There's a desire for more expertise from people who we'll need to satisfy anyway. Shouldn't have too prolonged a discussion here if we have to take it to another group and have the discussion again there.
  • KG: to that end, it sounds like the first step - the PING, rather than the TAG. Sounds like their reason for being.
  • KG: concurrently, useful to brainstorm ideas. Maybe don't get caught up on making a decision when we aren't the final decision makers.
  • BJ: seems reasonable reflection of how I'd like it to go. My experience with the TAG has been that most effective communication with them is putting up a proposal, or a couple of different options and saying: here's the direction we're trending, and let them critique. Don't want to figure out all technical details if we think it'll change. But if they can see where our thinking's going it'll facilitate the conversation better.
  • KG: don't want to invite them to join a debate. Point well taken.
  • MM: at one point there was a proposal in this group - timestamps or similar- didn't know the form it would take, moved into a separate document, then planned to move back - that would be valuable from our point of view.
  • KG: is this something we could use branches for, or other docs / explainers in the repo?
  • MM: we don't have any opinion about that.
  • BJ: I've seen explainers used successfully for that in the past. Focused on a single topic. It's conducive to bouncing ideas off groups like the TAG.
  • KG: good idea. Don't want TAG to have to trace through our massive spec just to handle this issue. Will have to go to them with the whole thing eventually. Like the idea of a separate explainer.
  • MM: it'd be an explainer instead of what's currently in the spec right now.
  • KG: was imagining it, we point them to the explainer and say ignore what's in the spec right now. Do you want to affirmatively remove things from the spec first?
  • MM: just because there's a prior example. I think it was pipeline statistics. We have 3 different proposals.
  • BJ: I think GPU name exists in the spec today. I don't' have any particular opposition to removing that. Don't think anyone will implement what's in the spec right now. Pulling up the explainer in its place seems reasonable. I'm happy to draw up a first draft of the explainer unless someone wants to jump in. Will pull in the discussions so far, why we want the feature, and a skeleton of a proposal, and we can discuss it in the group before going to the PING.
  • MM: sounds reasonable. This is an issue we've discussed "maximally" - we've talked up and down the management chain in our company. Have come up with 17 different ways it could work. I've intentionally refrained from proposing them because I didn't want to have the discussion. But since we've relaxed a bit, writing that document would be helpful, but we'll probably add a bunch to it before the TAG/PING get involved.
  • KG: suggest to make this a HackMD or Google Doc rather than initially a text file in the repo for ease of initial collaboration. That way we don't need tons of PRs - need brainstorming.
  • MM: if I understand correctly - we agree that Brandon will start writing a document, then I'll make a tentative PR removing GPUAdapter.name and add a comment pointing to the discussions in the other document.
  • KG: I'll talk with Corentin and Domenic about reaching out to the PING.

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

  • KN: this just came up in canvas formats discussion, so it's relevant. If we can reinterpret texture as sRGB, we can do that rather than allocating sRGB texture. Reinterpreting the base format.
  • KN: I put up a proposal a while ago. #2336. Tries to sidestep the question of "do we have a yes/no reinterpret flag" or "list of all formats you can reinterpret as", for sRGB in particular. Can discuss the whole gamut of the question.
  • KN: I don't really care, but I don't think a single bit is enough. There are ergonomic concerns about providing the whole list. Happy to do something in between.
  • MM: is the reason we're discussing htis now because we want srgb-to-non-srgb views?
  • KN: that's why it's at the top of the queue, yes.
  • MM: in Metal those are free. In other APIs they're not?
  • KN: correct. Nuance around it. Intel devices, according to our reading of open source drivers, even when they do know specifically they only need to reinterpret between e.g. rgba8unorm and rgba8unorm-srgb, they deoptimize, because framebuffer compression doesn't work on srgb formats (on older intel architectures?). Can be really valuable for drivers ot know this info.
  • KN: Vulkan used to only have a single bit - now has an extension with a list of reinterpretation formats. The driver would examine the list.
  • KG: but if you wanted it for free - we'd lose framebuffer compression even in cases where user didn't want srgb?
  • KN: not that old - Gen9 or 9.5, not that old.
    • context: Gen10 introduced in 2018.
  • JN: from D3D side - all recent drivers have to support free casting between sRGB and non sRGB specifically. Any broader casting, have to specify typeless formats to reinterpret components, and can't go beyond certain class types. Can't change channel orders or counts.
  • KN: thanks, didn't remember the D3D details.
  • RC: Jesse's right and years ago I put links into MSDN articles describing when it's automatic and not, etc.
  • MM: "all recent drivers" - is WebGPU expected to run on non-recent drivers?
  • RC: there's a desire to do that, yes. In my dream world, you don'tn need to maintain both WebGL and WebGPU - would like one API that works everywhere. E.g., disabling features of WebGPU, like no compute shaders on certain hardware - to extend the reach. We've discussed WebGPU Compat, though no longer in this format.
  • JN: in terms of era of drivers, circa 2017.
  • KG: that's encouraging.
  • KN: agree.
  • MM: Does Intel have comments / thoughts?
  • MM: this sounds like straightforward tier 1/2/3 thing.
  • KN: Not straightforward. Vulkan' doesn't look like that.
  • MM: tier 1 = one set. Tier 2 = bigger set. Tier 3 = even larger set.
  • KN: I mean - Vk API lets you specify reinterpretable format list. No boundaries between different tiers. The best we can do - look at real hardware and what it supports, and draw lines that look nice.
  • JN: I do believe Vk requires reinterpretation of all formats that are the same bytes per pixel.
  • KN: yes. Requires them to be possible.
  • JN: and all formats that fit into that category. No opt-out.
  • KN: can't figure out where to draw lines for perf purposes. Happen to know Gen9 doesn't support FB compression on sRGB formats, but don't know enough about other drivers.
  • KG: could take into account Metal's and D3D's expectations. If those don't perform super poorly on Vk, could adopt those. Castable sRGB support, for example, we'd always ask this.
  • KN: don't think we're willing to take that perf hit on Gen9. It's a big request.
  • MM: lowest tier would not allow sRGB casting. Next tier up, just sRGB to non sRGB casts. After that, would look at D3D and Metal tables and come up with something that makes sense. Maybe higher tier allowing all sorts of casting.
  • KN: did an exercise on how that'd work. Have to dig up the comment.
  • KN: my proposal: my #2336 creates one of these tiers - the sRGB tier. It punts on the rest of the question. Could either put the list there, or put more tiers in the enum. I'd like to accept #2336, sounds like it's inline with what the group's coming to.
  • KG: makes sense to me, could bikeshed on the name.
  • MM: think that's reasonable, agree with KG on the naming.
  • KN: we don't' have to land it now, but would like to accept the form.
  • MM: core of this - some devices shouldn't be able to freely cast between sRGB/non-sRGB, so give authors one bit of control per texture to start with.
  • KN: in that case, I'll see if we can talk about this in the editors' meeting. Think this is a good way forward. Would like tiers in the future, or lists - don't think it blocks this proposal.
  • KN: FWIW most of the people arguing to have the list are Corentin and Dzmitry, not able to be present at today's meeting.
  • SY: Intel driver's poor performance, we'll talk with internal driver team.
  • KN: I'll send you the resource we have. The driver says, on Gen9 do this, on Gen10 it's not a problem. I'll send you the info.
    • 168#issuecomment-965782693
    • after the fact: more thoughts:
      • We're pretty confident about the restriction being there, but we would be really interested in (at least qualitatively) how large the performance hit would be.
      • Another question would be whether the driver has any ability to dynamically enable and disable ccs_e based on whether srgb views exist of it. This I have no idea about. If the driver doesn't have to disable ccs_e on R8G8B8A8_UNORM until you actually create a view with format R8G8B8A8_UNORM_SRGB, then it would be significantly less of a problem. (edited)
  • KG: it's great to have confirmation from Intel.

Agenda for next meeting

  • KG: if anything for next week, please paste it here.
  • KG: look out for a survey for F2F times.
Clone this wiki locally