Minutes 2023 04 26

GPU Web 2023-04-26 Atlantic

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
  • TPAC in Sevilla in September?
• CTS Update
• “Tacit Resolution” Queue
• requestAdapterInfo() should be required to prompt (in at least some circumstances) #3962
• Allow importExternalTexture from VideoFrame #4063
• Can “internal” errors be surfaced in createShaderModule or are they always deferred to the pipeline? #4058
• Agenda for next meeting

Attendance

• Apple
  • Mike Wyrzykowski
  • Myles C. Maxfield
• Google
  • Ben Clayton
  • Brandon Jones
  • Corentin Wallez
  • Kai Ninomiya
  • Loko Kung
  • Shannon Woods
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Nvidia
  • Anders Leino

Administrivia

• TPAC in Sevilla in September?
  • CW: we don’t usually go to TPAC. It’s good for WebGPU members to go there and talk with people, but that doesn’t mean the group has to meet there.
  • MM: if we would have had a F2F around then anyway, doing it at TPAC makes sense. But not sure if we’ll have one then
  • CW: unclear what the cadence of F2Fs will be right now. Work will most likely have picked up by then though
  • CW: proposing we tell them we won’t meet at TPAC
  • …
  • KG: some tendency to have meeting close to the geographic center, but part of the reason TPAC moves around is to bring in people who are not. [I think we should meet at TPAC]
  • (agreement to consider meeting at TPAC)
  • CW: there is a question of travel budget on our side
  • CW: Will get back to yall this week.

CTS Update

• KN: Ryan’s been finishing up generalizations of numeric testing, so that we can test AbstractFloat and f16 soon, so f16 testing is something we expect to start happening soon, even though it’s difficult for us to ship. I think Intel will be working on that.
• KN: On the API side, I’m working on fixing up our texture format stuff. This should improve our testing. Should be done soon.
• KN: Contributions are always welcome!
• JB: Currently working through the webgpu-samples to prioritize work and other popular examples like Web GPT. Haven't used the CTS yet because working on these popular samples gives more bang for the buck at the moment. Hopefully CTS becomes more of a focus soon.

“Tacit Resolution” Queue

• Nothing

requestAdapterInfo() should be required to prompt (in at least some circumstances) #3962

• BJ: We discussed this last week, tried to clarify what the current API is doing in Chrome, and what the intent behind removing the hints was. Myles said he would talk with his people
• MM: not super happy removing the hints because it’s important that websites can ask for the things they need in a deliberate way. Don’t like the idea of saying “.device” is a signal that you read it, that doesn’t convey deliberateness well.
• MM: because Chrome isn’t going to prompt, and isn’t going to give anything except vendor/architecture, we’re not super worried about this right now. Think this should be revisited if/when this policy changes in other browsers, but for now think it’s OK to move on.
• CW: with consensus on the removal of unmaskHints?
• MM: no
• KN: So we want to leave the spec as-is, with the knowledge that it’s incorrect with respect to one implementation, and that we don’t intend to fix it? Would browsers always prompt, to avoid having to add a prompt later?
• MM: Right now, you’re giving away this information without a prompt. When we want to give away more, we’d have to discuss that. It would help if we just rejected the promise when users ask for any more details.
• KN: This is what we do now: we give you the vendor and architecture, and if you ask for anything more, we reject.
• BJ: If you only ask for the vendor and arch, we won’t reject, but if you ask for anything more, then we will reject the promise
• MM: That’s okay with us, because it will discourage authors from asking for more
• BJ: Concern is, even if we reject the call, if we do so silently, then there is the possibility that we build up a mistaken sense with developers that, “I can just call this with reckless abandon, and the worst that will happen is I’ll get a rejection.” Then if we add a prompt later, it’ll cause problems. So we wanted to remove the unmaskHints dictionary now, and then add it back if we had other information we wanted to expose
• MM: That assumes other browsers won’t be showing a prompt.
• CW: We’re ready to move on without changing anything
• MM: If browsers make changes here, please as a courtesy let us know in advance

Allow importExternalTexture from VideoFrame #4063

• KN: This pull request adds VideoFrame to the things you can make external textures out of. It describes how they expire: only when closed. Just letting them get GC’d won’t expire them. But of course, you should not drop frames without closing them, because that makes decoders stall. This seems like the simplest approach for integration
• KG: It’s good that you’ve called out exactly what counts as “closed” - but I’m worried that this list may be incomplete. Perhaps “such as” would be better? We might, behind the scenes, want to close video frames early, and then that wouldn’t be captured here.
• KN: I don’t think the webcodec spec allows closing video frames early.
• KG: I hope it does - really bad things happen if you can’t
• KN: If the impact is limited to the page that made the mistake, then I think that’s how WebCodecs is designed
• KG: our spec should just make it clear that it’s not a complete list
• KN: If the list isn’t complete, then the spec should be changed.
• KG: If you don’t want to loosen up the language, then I need to talk to my experts again. If we want to finish this promptly, then we should loosen the language
• CW: We could just use the word “close”, and then let WebCodec decide what “closed” means
• MM: Would we want to add our own close method?
• KG: If you keep a frame open too long, many platform decoders will deadlock. So if you’re leaking these frames, then unless we do behind-the-scenes work to make copies, then we’ll deadlock it. Maybe we’re saying that’s fine, but it seems like the spec would want to leave room to close things peremptorily to handle those cases.
• KN: There is a thing called closeVideoFrame, it’s not exported, but we could refer to that: “whatever calls this”. So, yes, let’s change the spec to refer to closeVideoFrame, and then we’ll catch anything that closes the frame.
• KN: But, also, I don’t think the WebCodec spec leaves any possibility of closing things peremptorily. But I can make the requested change.
• MM: We discussed this with our WebCodec team, specifically this issue - we concluded that it’s not a WebGPU problem, it’s a WebCodecs problem. You can trigger this problem today without any WebGPU at all, so 100% of the well-behaved WebCodec applications, WebGPU or not, will be closing their frames. We’re adding a reference to this object, so I thought we were making things work - but if the applications are indeed working properly, and explicitly closing their frames, then we’re not making the situation worse at all.
• KG: I’m just concerned about encoding our current understanding of webcodec in the WebGPU spec
• KN: I think we’re all in agreement - I’ll make the spec changes. But, do people agree about adding the feature?
• KG: I think nobody will use it.
• KG: People should be using the path that lets us get the sampling right for them automatically.
• KN: It’s the whole video frame, all planes
• MM: This seems reasonable to me because VideoFrame is already an imagebitmapsource, so it makes sense that WebGPU should accept it too
• CW: In terms of usage, the application we’re using now uses WebCodecs and WebGL for processing. IF they switch to WebGPU, they’d definitely be using this path to introduce the data.
• CW: Sounds like mostly thumbs-up, do we want to review again after KN revises?
• KG: Let’s just land it
• KN: Okay, I’ll update, and the editors will get it landed
• KG: Please nobody write a “best practices” doc that recommends VideoCodec
• MM: Hmm, not sure I agree, but let’s move on

Can “internal” errors be surfaced in createShaderModule or are they always deferred to the pipeline? #4058

• CW: I thought we’d agreed on something, but what was it?
• KN: We’ve talked about this so many times, I can’t find the resolution
• KN: Question is: for errors that come out of the backend, “internal errors”, like, ran out of registers - things that we can’t know, that the driver can know - can these be surfaced in createShaderModule, or can they come out of createPipeline?
• KN: I think pipeline, because: implementations should be able to move verification around without breaking applications
• MM: We could spec that it must occur in one place, or the other, or either. Requiring it to be reported at createShaderModule is right out because Chrome doesn’t do backend shader generation until pipeline creation time, so that option is out, so we only have two options: permit either, or require at createPipeline
• CW: For application development, it doesn’t seem like it makes a big difference. It seems like “no” to me, because the error will propagate to the pipeline anyway, so you can just check there. It would only bother people who check shader creation but not pipeline creation, which seems unlikely. People should check at pipeline creation time because there are always steps that can’t be done until that stage
• KN: So as long as there is an error at pipeline creation time. Then it doesn’t matter so much what we do with module creation time
• MM: We’re hoping that people will create shader modules earlier, and reporting errors earlier is beneficial to developers.
• KG: We expect to generate console messages as early as we can, so developers will see it soon no matter what. But we don’t want to encourage people to write paranoid code that has to wrap createShaderModule just in case. One benefit to requiring that errors be delayed to createPipeline is that people can count on them being there
• MM: IF you’re compiling early, and createShaderModule produces one of these errors, and the user doesn’t check, then it makes sense to produce the error again, at pipeline creation time
• KN: That’s my preference as well
• MM: The other difference we’re hoping for is that one module will create many pipelines. So it’s also beneficial for the dev to know that no pipeline will ever work with that module, and not bother trying to fiddle with parameters
• KG: We shouldn’t worry about rare use patterns.
• CW: Also “uncategorized” (internal) errors can always happen late - at the very least because of override constants. So they’re always going to be able to happen there
• MM: Should createShaderModule also be able to produce “uncategorized” (internal) errors?
• JB: In order to give a good DX we will always collect the errors and carry them forward to the place that's convenient to surface to the developer (even queue submission). There will always be plumbing of errors around so it doesn't really matter since the error will be carried. There is no additional complexity no matter the choice here. So everybody can do everything here.
• CW: I’m hearing that in our implementation, we don’t care when it’s required, and JB is saying there’s no additional complexity around reporting it later.
• CW: In the uncaptured error case - it’s raised at module creation time but nobody catches it and it becomes an uncaptured error - that could cause the application to behave in a drastic way. Uncaptured error scope is often going to be a bad user experience
• MM: We can tighten the spec later, if we leave it loose now
• KN: To MM: I don’t quite understand the suggestion: which should we do now?
• MM: Making the spec require that error messages are not exposed from createShaderModule - a browser can try exposing them earlier, and see if it’s okay in practice, and we could change the spec if it is
• KN: We could also just have createShaderModule take an option that says, I want errors now. Seems simpler than doing a web experiment
• MM: There’s a window of time in which the only shipping implementation will never throw from createShaderModule - and then other browsers will introduce other behaviors - and apps written after the window will be better behaved
• KN: Internal errors are going to rare and difficult to test already, so I’m not sure having multiple implementations is going to help much. People are going to need to have exactly the right hardware. It’s always going to be a niche problem, so I’m not sure it matters how many implementations we have
• CW: Let’s not have another meeting next week just for this issue. It seems like we can permit it only at pipeline creation time. This will be rare, so it probably doesn’t matter.
• KN: If we find out that it matters, we can cope with it then.
• KN: On the topic of propagating errors forward, the proposal would have propagated an internal error forward. The spec only propagates validity, not full errors.
• KN: If get an internal error in createpipeline, should that cause internal errors later, or validation errors later? Spec says validation, and I think that’s right.
• MM: We think having the types of errors reported by later stages be different is okay.
• CW: Consensus on reporting at pipeline creation time?
• CONSENSUS

Agenda for next meeting

• NO AGENDA FOR NEXT MEETING
• Various people have various extensions they’re interested in, but they can wait for later
• CW: will check with Intel, but otherwise, no meeting next week, if you have material for May 10 meeting, place it below
• Handling of omitted labels is unclear #4083
• (?) Fingerprinting Surface #3101
• More promise ordering guarantees #4117