Skip to content

Minutes 2022 01 26

Jump to bottom
Corentin Wallez edited this page Feb 1, 2022 · 1 revision

GPU Web 2022-01-26

Chair: Kelsey

Scribe: Ken / others

Location: Google Meet

Tentative agenda

Attendance

  • Apple
    • Myles C. Maxfield
  • Google
    • Brandon Jones
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
    • Loko Kung
    • Yunchao He
  • Microsoft
    • Jesse Natalie
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Kelsey Gilbert
  • Unity
    • Brendan Duncan
    • Dave Shreiner

CTS Update

  • KN: nothing big after last week.
  • KN: some work in for state tracking stuff. Loko's been working on Device.destroy() CTS tests. Other small fixes. Tests for swapchain formats.
  • KN: added feature showing completeness of subtrees of the CTS. How many tests have TODOs.

Triage the issues without milestones (timebox 15m).

  • #2252 support for Wasm memory64
    • Probably post-V1.
    • KN: Wasm64 is fairly early.
  • #2359 last vertex buffer element...
    • KN: I think we can make this V1. Should be small change to the validation.
  • #2438 Silence compilation errors
    • GT: I'd like to display errors my own way, but WebGPU's displaying them its way in the console.
    • MM: sounds like an extension to disable console logging.
    • KN: made proposal about what browsers should do with their DevTools consoles. Basically editorial. Call this part of that?
    • BJ: not aware of any specs that dictate console behavior. Anything we do will likely be non-normative. Could safely say, push back to post-V1. There are ways we could normalize the behavior here.
    • KG: could we call this post-V1 but work on it anyway?
  • #2469 why are bind group layout fields spelled differently than in WGSL
    • DM: I think it's OK that it's spelled differently. We have textures of different types that all come down to u32 in the shader, and we're not trying to normalize those. It's OK if the types are different.
    • KG: that's a vote for closing this.
    • KN: no strong opinions. Would be v1 if we didn't close it.
    • KG: will say milestone V1, and if you want to close it, that's the right process. Changes here should go into V1.
  • #2500 WebNN / WebGPU interop
    • RC: ok with me if this is after V1.
    • MM: good idea though.
    • KN: should work on this, but can be post V1
  • #2520 handling OOMs when resizing canvases.
    • KG: this is V1.
    • KN: agreed.
    • KG: discuss in detail later.

Discuss the WebGPU Adapter Identifier explainer before reaching out to the PING.

  • KG: did people have a chance to review this already?
  • MM: I had time to skim it. Fairly disappointed of the formulation and structure. Seemed to be structured in a way to describe all the reasons we need a particular solution, rather than placing a collection of solutions on the table and listing all their merits.
  • MM: I think the next step here is for me to make a bunch of proposed edits, and we go from there.
  • BJ: I think there ight be a mixup in perceived terminology. Typically, when putting together web spec explainer, you don't propose a bunch of variants. Usually, they're presented - here's the direction we want to go, more lightweight format than a rigid spec. Usually presenting a concrete path forward that can be iterated on. That's what I tried to go for here, in the same vein as other explainers I've written and this group has too. If we're looking for a collection of proposals, I'm all for that - would like to hear what you said were ~17 different proposals. Would like group to have opportunity to see different directions we could go, weigh the pros and cons. In the last call when I was asked to put together explainer, this is what I had in mind coming out of that. Advocates for that direction because that's what an explainer should do.
  • MM: explainers aren't what my team usually create, so I didn't know the intended use / structure. Think the problem in front of us - there's a spectrum of different options, there are pros/cons, we would like experts to help us decide. I don't think this group has a particular option we think is the right path forward. I don't think this represents the group. If we think that's the structure then maybe we shouldn't put out an "explainer" per se. Apologize for misunderstanding. 17 was hyperbole, I think we had 3 ideas. 2 already in the explainer, so 5 total.
  • BJ: there was never an expectation on my part that the content of this particular explainer would go to the PING unmodified. A lot of the motivation/reasoning in this doc will hold true no matter what direction we go. But the proposal of how we address it is just the last proposal I had, and I expected that to be altered before going to PING. Don't feel bad for the work that went into this. I would love to see alternate proposals, we can shop them around the group.
  • KR: please put proposals in the doc. The motivating feedback from developers is valuable and I don't support removing it.
  • KG: ... to paraphrase Myles, expecting to make edits to it, not to scrap it. Think we're in a good collaborative direction though we had a conflict of understanding of the term "explainer". Thanks Brandon for writing this up.
  • BJ: to clarify: if Myles would prefer to put alternative API shapes into this doc, I think you should already have edit access as long as you're signed in to HackMD. Or, if you prefer to socialize that feedback in the issue itself before we pull more group consensus in this doc.
  • MM: don't want to make work for you. Would work best for me if it were in a Github repo I could make pull requests against. Helps people see diffs and I'm not just going in and changing your words. More rigorous than that.
  • BJ: to clarify - can think of HackMD as Google Docs for Markdown - it does keep history. I really don't care where we maintain this doc going forward. If Markdown in Git repo works better for you - that's fine. As long as we keep forward momentum.
  • KN: we could use Google doc with proper suggestion interface too.
  • KG: up to you all. My preference is HackMD - PRs for these things seems like too much process. Want to make it easy for you Myles to make edits.
  • Discussion about process.
  • KG: the more immediately collaborative we can be the better. Sounds like a Github doc is what you want.
  • BJ: I will take this doc, save a copy onto the repo as Markdown, please feel free to make PRs against it if that's the most comfortable way to contribute. Won't push back too hard on changes here. Primary concern, let's get any alternate API shapes in front of the group as soon as possible.

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

  • KN: Intel talked with their driver team. Confirmed: no FB compression for sRGB formats prior to Gen10. Given that market, we can't put reinterpretation of sRGB in core by default.
  • KN: my proposal still stands: add sRGB reinterpretation bit. Most important for writing linear values into canvas textures. Question of list vs. tiers remains open.
  • MM: That was really helpful. Think your logic is sound for not allowing this without opt-in. Q then: what's the opt-in mechanism. Think a bit's reasonable. In the future I think we'll want to expand beyond a bit. If we add a bit today what will API surface look like? List? Tiers?
  • KN: PR adds new member to dictionary, viewFormats. Has an enum type. Only one value right now. Unspecified = no reinterpretation, or sRGB-ness. If we did tiers - we could add items to the enum. List, could do union with the sequence. There's a block of IDL higher up proposing something different. Instead of a tier list, it's a set of reinterp capability bits. Not compatible with my proposal, so we would need to consider that now if that's the direction we want to go.
  • DM: to clarify my concerns: if we go this route we're bringing a new problem of how to specify different reinterpretations. sRGB is clear. Outside that there's a lot of implicit knowledge about what's performant in drivers. E.g. AMD drivers, float/int casting is devastating, but int/int is cheap. Would prefer not to opt into classes, but types. THen it's future-compatible.
  • MM: think the fact that Metal has 3 classes and DX also has classes (there was a spreadsheet somewhere) indicates that the state is that there really are classes of devices. If I understand your point, one consequence is that we might have a situation where there aren't really classes, but casts between types that have different perf characteristics. If all devices' behaviors were wildly different, I think you're right - a set of formats would be the best API. The evidence I'm coming from is that D3D and Metal do have these tiers, so I think device classes do fall into this model.
  • DM: I don't think D3D offers you this unconditionally. If you create typed formats, can only cast in a limited way, if at all. Once opting into untyped, D3D has to be more pessimistic about what you can do. Not necessarily a good API example to follow.
  • JN: 2 distinctions: capability vs. what's recommended / performs well. One, what's device capable of doing? Can you cast between things in the same class? sRGB or not? Different channel counts? D3D caps there are less than other APIs. Then, performance. What should you do? Create typeless format, expect as good perf as typed? We don't have exposure to this on any APIs - depends on the hardware you're using. Goes back to adapter ID. You'd know what's performant on different GPU types.
  • DM: even if you know what you want to do, like signed int -> unsigned int cast, you can say it. With classes, you can't tell the GPU what you're trying to do, and can't reach the code paths where the cast might be free.
  • JN: makes sense. D3D is in the process of adding a Vk-like format cast list functionality.
  • KG: think that's where we may end up in the form of an extension, or core later on. Do we want to jump straight into that? Or just reinterpret sRGBs?
  • KN: knowing D3D's going in this direction is helpful. Gives us more incentive to do it now. We can pass that data directly to D3D. I think the only problem with a format list is ergonomic. We can deal with it in our impl. Don't think ergonomics of a list are that bad. For sRGB, list one more format in your view formats list. Most people don't need to do reinterpretation among large format list. I'm more in support than before of just doing a format list now, knowing D3D's going in this direction.
  • MM: think this is not a hill I or my team are willing to die on.
  • KG: should we see what a list looks like then?
  • DM: you mean in the IDL?
  • KG: and examples of this case. Not that complex to write down. We should try to spec it.
  • DM: you want to use this for canvases? But we don't create textures for them.
  • KN: in my PR, I add this to the canvas configuration dictionary too. Almost the same as texture descriptor. Mainly editorial.
  • KG: sounds right.

(stretch) Expose WGSL errors in the API #2308

  • KG: I imagined this going into the compiler info feedback.
  • MM: we already have errors exposed in the API. Are uncategorized errors special? Maybe yes - we don't know those until we hit the driver. In some situations WebGPU won't see the errors until you create the pipeline.
  • KN: dependent on pipeline creation anyway. Depends on pipeline overridable constants, etc. Register allocation for example - what to do if driver needs to enable things like shared memory per pipeline.
  • MM: uncontroversial that pipeline creation's fallible. One option - have it return null? Internal error state, I guess. createShaderModule's really elaborate. Probably some middle ground. A single enum?
  • MM: think the answer to this question will come from what author should do in response. If they should change their pipeline, we should give them detailed info - otherwise, a boolean.
  • DM: think we'll know what happens at shader module creation. But not at pipeline creation. Because shader module creation happens mostly on our side.
  • MM: at least in Metal there is an error options the driver can pass back. "I couldn't allocate registers, please use fewer variables." There's a mechanism for it.
  • KG: I'd like a mechanism even if it's mostly "general internal error".
  • MM: proposal: make a function on pipeline state that returns Promise<enum> and right now the enum has one value, "unspecified error". Later we can expand the enum.
  • DM: how to get the real error out?
  • MM: Cocoa error handling: NSError containing string. Also error IDs with specific meanings. In proposal you wouldn't do that. Only one value in the enum that would ever be returned.
  • KN: makes sense.
  • DM: there is an error ID we can match in the future.
  • MM: yes.
  • DM: ok, hadn't seen that.
  • MM: check docs for NSError.
  • DM: where to return that enum?
  • MM: a new function on PipelineStateObject returning a promise. Would give Intel a way to know when compilation's done, too.
  • KG: in WebGL we hit the driver before it's done.
  • MM: existing error mechanism's not sufficient to know how long compilation took.
  • KN: ties into current error handling. Shader, pipeline creation not queue operations - not enqueued the way other stuff is. Trying to order the ops to do ErrorScopes was a little iffy. We could do this, and remove pipelines from error scope reporting. This is the way to get errors from pipelines. Separate question from this. Works well with it though.
  • DM: talking about all pipeline errors or just the weird ones? Other errors are no different than resource creation.
  • KN: also thinking about this for other resources, but haven't fully formed a proposal.
  • MM: another idea: use existing error reporting mechanism, and add a new filter type.
  • KN: yes.
  • DM: seems equivalent if you wrap your pipeline creation call.
  • MM: ordering's a little different. Standalone function returning a Promise has different ordering guarantees.
  • DM: why does Intel need to know when the pipeline's done creating?
  • MM: they want to detect compiler performance regressions.
  • KN: sounds like I should think more about more general error handling changes. But I think one of the two solutions is the right one - either ErrorScope filter or another function you access.
  • KG: hope we don't rely on standardized enums but also have an error string that's reported by the driver.
  • KN: agree.
  • KG: situation I assume is that you couldn't create the pipeline after all, and you only find out async.
  • KN: could also happen in async, that the driver couldn't create it.
  • KG: if only had async version, would want to add this as fields to the thing we'd return.
  • MM: agree. In the past I'd argued that async creation should be the only one WebGPU supports.
  • KG: don't you have this for free when you use it? Maybe using a pipeline's not trivial. You try to use it and ErrorScope says, "that failed"?
  • KN: async version will reject with an error. Doesn't even go to error scopes. Not sure we wrote that down.
  • MM: next steps? Kai thinks, then writes down proposed answer?
  • KG: maybe.
  • KN: I'm willing to.
  • MM: willing to follow that plan.
  • KN: don't think the final proposal's going to diverge far from what we talked about here.

Agenda for next meeting

  • Adapter Identifier explainer
  • Non-ratification-track and pre-ratification-track development
    • [Process] Add RequirementsForAdditionalFunctionality.md #2424
    • Add extensions directory and pipeline statistics extension doc #2301
    • Where do we spec WebGPU-WebCodecs interaction? #2498
Clone this wiki locally