Minutes 2022 06 15

GPU Web 2022-06-15

Chair: KG

Scribe: KR, KN

Location: Google Meet

Tentative agenda

• Administrivia
• CTS Update
• “Tacit Resolution” Queue
• Try-catching getMappedRange is useful but shouldn't be #3013
• [TAG review] Should there be a higher granularity for selecting devices? #2945
• [TAG review] Wondering if power consumption choice should be initiated by the user #2946
• Provide stronger control over physical alignments of buffers and bindings #3021
• (stretch) Expose the buffer state as an attribute #3014
• Agenda for next meeting

Attendance

• Apple
  • Myles C. Maxfield
• Google
  • Ben Clayton
  • Brandon Jones
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Stephen White
• Microsoft
  • Jesse Natalie
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Unity
  • Brendan Duncan
• Michael Shannon

Administrivia

CTS Update

• KN: contributor from Igalia ramping up nicely and getting some work done on the CTS.
• KN: completed switching off WPT. Chromium running WebGPU tests in same harness we run WebGL in. Working on suppressions for known driver bugs.
  • KG: suppressions for known driver bugs - feel these are things we shouldn't share with each other. Should communicate, but shouldn't mark in the CTS. Browsers should know about, handle differently. Different markings as we fix workarounds?
  • KN: we'll diverge b/c of differing hardware, drivers, workarounds. Agree we won't want to disable tests unilaterally, probably. But more likely that we'll have a database of known driver bugs.
  • MM: are you proposing deleting something? Or moving something outside webgpu cg's jurisdiction?
  • KG: suggesting not adding something. Not deleting anything. E.g., you detect it's a Windows common GPU, and know there's a driver bug. Probably shouldn't make this automatically make tests pass, when failing, because we detect the GPU and say it's problematic. Valuable to share the information. Thinking - maybe useful to have the test marked/annotated. "some browsers have marked this as a driver bug". Don't want auto enabling/disabling.
  • KR: Based on experience from WebGL, I think it’s important that the top of tree conformance tests be expected to pass on every browser and every graphics card. In WebGL we came up with rules that, if a given platform+browser supports more than one GPU, it must pass on at least two. That’s how you know you’re not specialized to one GPU. Here, talking about very precise suppressions. What we’re talking about doing here is skipping certain CTS subcases wholesale and essentially say, developers can’t rely on this behavior of this texture format working portably. Yes, saying skip the testcase everywhere because of a specific driver bug we can’t work around. Agree when it comes to specific configurations we test it makes sense to maintain expectations in browsers. We need to have some solution inside the CTS because the harness can’t reach inside and disable just one subcase.
  • KG: Have also found we want a way to suppress very precisely. Think we agree just with different words.
  • KG: Would want errata in spec. Don’t want to spec via CTS.
  • MM: last sentence that KG said- agree. If a texture format / feature doesn't work, that info should be in the spec. CTS test should match what the spec says. Mechanism here isn't, it's broken, skip in the CTS - first we modify the spec, then i'd say, delete the test.
  • KR: Need to carve out very specific cases of parameterized tests. Don’t think we should remove tests because there’s a full expectation that we pass them in the future.
  • KG: Think we’re close enough philosophically that we can hash out details on a case-by-case basis. Think we shouldn’t try too hard to get perfect philosophical alignment.
  • MM: understand what you're trying to say. Mechanism Ken describes exists. There's a filter option in teh CTS harness, you make N-dimentional thing to test, and don't test this or that combination. Only difference between existing filter mechanism and proposed one is in-band vs. out-of-band.
  • KG: excited to have poke-out suppression mechanism. That'd be ideal.
  • MM: that already exists.
  • JB: i'm excited for Mozilla to leverage the size of Google's team to not debug specific issues on graphics cards, take a team member who's the only one who has that card to drop everything and debug this. Would like to ride on Google's coattails here.
• BC: more general update on CTS stuff: one team member implementing WGSL correct interval (floating-point) logic. New framework he's been developing, has landed, tests are being moved over to it. Worthy of announcement. Deals with e.g. functions depending on other functions.
• BC: other thing - added in new constexpr variants. Variants of tests injecting values into shader. Will decorate with "const" keyword, forcing evaluation in WGSL compiler.
• MM: if particular driver / device that fails a subtest - surprised we'd skip it for everybody. It's a real bug.
• KR: Common situation is we can’t expect a driver bug to come out for many months. And can’t be worked around. Example is Intel GPUs on macOS where they may never get driver fixes. In these situations I’d propose adding errata.
• KR: For official conformance, not supposed to run inside our harnesses, need to run in the open web.
• KG: think we agree where we need to end up, but different ways of getting there because of the histories of the two working groups. My impression - one approach: when we find these issues, correct thing to do is to open an issue, talk about it in the group, and decide case-by-case what to do, in the community group. Main disagreement - do we patch the test suite first, or do we spec the change first? Result should be the same. Ship on these devices, then fix the driver bugs.
• KR: Agree with the process. We need a mechanism to suppress subcases out-of-band where we can list the suppressions and describe the bugs in detail.
• KG: if you propose PR, process, etc. we can talk about it. Hard to say up front that that's what we want.
• KN: i don't think we have to worry about the approval at the technical level. Let's just get to the point where we need a process.
• KG: ok.

“Tacit Resolution” Queue

• <queue is empty>

Try-catching getMappedRange is useful but shouldn't be #3013

• KN: problem here: can be useful, rather than waiting for the Promise from mapAsync, poll getMappedRange to know whether map's completed. Right now, getMappedRange will tell you whether map's completed or not. Will do so by throwing an exception if the map's not ready. Want exceptions in our API to be things you've done wrong. Very useful to separate concept from "thing you've done wrong" from "here's an answer to your question".
• KN: don't want people to write try/catch around getMappedRange because they might catch stuff they shouldn't be, and suppressing their own bugs, and their app blows up because they thought it was one thing but it was different.
• KN: could make exceptions distinguishable - think not necessary.
• KN: editors discussed this. Read-only attribute about what state of buffer is? TBD granularity. Then just look at the state. Previous proposal to return null from getMappedRange, but decided to not do this.
• MM: was going to discuss exposing state, but never mind.
• KG: interesting to think about null / exception / different exception type.
• GT: in webgl we have the concept - things like thisi can't change state in the same event. you'd get throwing behavior until you yield.
• KN: yes. this is the same. this proposal doesn't change when mapping occurs, only how you find out the mapping's completed.
• KG: we tell people to wait for the promise. authors should wait for it, then after they get it back, they call getMappedRange. if that's the approved way of doing things, throwing an exception here makes sense. you broke the api contract.
• MM: agree - in current API phrasing, exceptions should be thrown for things you do wrong. i believe the api's correctly designed as is. separate question - what if someone wants to know if they can call getMappedRange right now? if this is a problem authors are running into, and want to know without sticking expando property on the buffer, it's a natural solution to give them an answer to their question.
• kn: good summary.
• kg: should this be a function call or an attribute? different. attribute, will have to eagerly fill with data - but actually no, those getters can be a function call. so they're equivalent.
• kn: agree.
• kg: kai's saying people are bringing this up often enough that we don't want to force them to use exceptions.
• kn: yes.
• mm: there's precedent on the web platform for exposing this status as an attribute rather than a function.
• kg: i'm convinced.
• …
• kg: only thing, documenting how the attribute updates.
• mm: if we're in agreement, procedural question - we have about 5 different states. mapped at creation vs. mapped. procedurally - does this group want to review / do we need to discuss these specific enum values in this enum? or can whoever writes the PR update it?
• kg: i thought it was going to be a boolean.
• mm: fine - but maybe we want it to be an enum so we can add more values later.
• bj: wouldn't we want unmapped, pending, mapped?
• kn: maybe.
• bj: think myles is right, think we should just take a stab at it and iterate.
• kg: +1
• kn: i have mapped, … , and locked - multithreaded api could say, it's mapped somewhere else, but don't need to figure that out. doesn't expose pending vs. unmapped.
• https://github.com/gpuweb/gpuweb/pull/3014
• kg: let's look at that pr offline.
• kn: if opinions please comment there, otherwise editors will continue discussion.

[TAG review] Should there be a higher granularity for selecting devices? #2945

• BJ: can i express surprise that they want us to be more detailed about this stuff?
• MM: TAG's composed of many people from many different companies. :) I have to say this is a bad idea. we view it as a feature that the number of addressable devices is bounded by the webgpu api itself rather than the system. want boundedness to be as small as possible. we think a request like this should be driven by web developer needs of authors in the wild.
• kg: +1. would be interested if people came to us deliberately with this request. not to add in v1.
• mm: almost every machine has 1-2 devices. would be surprising for us to hear that someone's looking for this, can't get it by asking for high-performance gpu.
• bj: if we ever get an explicit request from users for this - think it'll come from science / academia. big servers, racks of gpus. want the web to address all the things. will be glorious day when we get there. :) but think it's a ways off. happy to hit 99.9% use case here.
• kn: agree with this being post-V1.

[TAG review] Wondering if power consumption choice should be initiated by the user #2946

• kg: give more choice to the ua here?
• mm: already have this - it's behind a Promise. the ua could show a UI. the ua can return whichever device it wants. think we have this arleady.
• kn: agree.
• bj: agree too. we don't have spec language - you request high-power device & one isn't available, you have to reject? that's the only thing that i think would prevent this.
• kg: don't think so.
• bj: think we're ok then.
• kg: closed.

Provide stronger control over physical alignments of buffers and bindings #3021

• kn: interesting topic. started with an issue david filed. alignments that are declared by the shader might not end up being physical alignments in physical memory. in order for that to be true - not only do you need alignment in shader, static offset, and allocation of buffer itself all have to be aligned.
• kn: need for this - if app wants more control over physical alignment, generally for perf reasons, previously - thinking you'd need to use alignment in shader, alignment inside buffer would be what you want. if we want to guarantee this, have to propagate all the way out to GPUBuffer.
• kn: alignment you request could be arbitrarily large. can't propagate it in that way.
• kn: thing to discuss here: do we need anything like this for v1? i put it in v1 only to surface it. think definitely post-v1 candidate - provide some control over GPUBuffer allocation alignment, and help the developer get things aligned when they want them to be. 2 decisions in the issue. don't think we need either right now. wgsl group's discussed somewhat. this is the api side. think again post-v1, and we'll see what people need in the longer term.
• mm: agree. let's not do it now.
• kg: agree, could add it later.

(stretch) Expose the buffer state as an attribute #3014

• already done

Agenda for next meeting

• kg: That's the agenda! :)
• kg: on wgsl side, also running thin on issues we have to talk about in meetings. still have issues, still need to write spec text, proposals, and discuss.
• kg: call to action - go through old AIs / issues, see what you signed up for, and do it!
• kg: then we'll start digging into issues where we're waiting. try to make progress in the group. but that's it!
• kg: let's plan to meet next week as normal. if really no items, we will cancel. think we will have an agenda.
• Agenda
  • maxColorAttachments not sufficient? #2965 (comment)
  • Specify that texture_external sampling functions clamp coords to [0, 1] #2766

Upscaling

• mm: one optional agenda+ item - ask people what they think about potential upscaling extension . something the industry's moving towards - becoming more popular. MetalFX, NVIDIA DLSS, AMD FSR… . not actually part of graphics APIs - built on top. in scope? valuable? good/bad idea? thoughts please.
• kg: talked a little in the office hours. maybe cool thing here we can offer. tie into native apis. worth investigating. esp. if plug-and-play at impl level.
• rc: how would such an extension work? render target level? shader? how exposed?
• mm: upscaling usually done in intermediate pass. HUD drawn at native res for example. commands that do the upscaling have to be in middle of frame. some function call on the command buffer or render encoder. like an opaque call, do the upscaling now please. configure with appropriate descriptor.
• bj: discussed a little in editors meeting. you basically hand it a command buffer, fill it with the upscaling commands. injects commands for you. not like it's taking the render targets and doing something crazy behind the scenes. just building command buffer. amd version of this is open source. not a lot hardware specific.
• ms: you're correct, it's hardware specific. biggest challenge: some upscalers require lots of data, some don't. that difference might be the biggest challenge.
• mm: if interested in pursuing this - different models we could use. maybe, you have to give us all the necessary information for all the apis? or go with texture compression model & have different extensions? con of first - non-portable. research needed. if we told the developer it'll be upscaled somehow - will that be good enough?
• ms: one way to resolve - please provide the actual framebuffer itself and velocity data. can always guarantee an upscale via FSR 1.0 because it doesn't need velocity.
• mm: that's true.
• bj: developers could implement some form of this themselves. tempting to say - you should just do that. comparison to mipmapping libraries. in this case, one key component is the models behind the upscaling can be large. diff between asking developer to bundle this up into wasm, vs. using version on your machine - good reason to expose this via a mechanism that can hook into the native version.
• kn: another reason - with DLSS (not sure if we can use that), pretty sure they're hooking into cuda / tensorcore stuff in the gpu, and we can't expose stuff like that.
• kg: think there's appetite for a proposal and investigation.