Minutes 2023 03 08

GPU Web 2023-03-08

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 mostly

Location: Google Meet

Tentative agenda

• Administrivia
  • Publish the explainer as a companion Note to the specs?
  • More repos in the github.com/webgpu org?
  • WebGL+WebGPU meetup at GDC
• CTS Update
• “Tacit Resolution” Queue
• add query for list of WGSL software extensions #3875
• Who actually wants multiple timestampWrites with the same TimestampWrite.location? #3808
• Fingerprinting Surface #3101
• Adapters should not be allowed to expose contradictory workgroup size limits #3888
• depthWriteEnabled and depthCompare are required even for stencil-only formats #3905
• Limit for the maximum resource size? #3916
• Agenda for next meeting

Attendance

• Apple
  • Mike Wyrzykowski
  • Myles C. Maxfield
• Google
  • Ben Clayton
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
  • Shrek Shao
• Microsoft
  • Rafael Cintron
• Mozilla
  • Jim Blandy
  • Kelsey Gilbert
• Nvidia
  • Anders Leino
• Mehmet Oguz Derin

Administrivia

• Which meetings to have APAC?
  • CW: Kai suggested doing every 4 weeks, does it work for everyone?
  • (No response)
  • CW: Will check with WGSL group
  • …
  • CW: WGSL will decide whether we’re APAC or not, and we’ll follow.
• Publish the explainer as a companion Note to the specs?
  • CW: suggest we do this.
  • MM: can we have some time to review first?
  • CW: sure.
• More repos in the github.com/webgpu org?
  • https://github.com/gpuweb/types ? (TypeScript type defs?)
  • BJ: have some best practices docs. Benefit from more central location. Would like to decide what kinds of resources/tools we want under here so we don't need to keep asking this question again. For example I have a shader comparison tool. A little tricky because it references shading languages other than WGSL.
    • MM: think if we want to post best practices they should be widely reviewed. Different architectures & WebGPU impls will have different best practices.
    • KG: I expect best practices will likely show up on MDN. WebGL Best Practices are hosted there. Found a good process for this. Don't want to canonize too many things. We need samples. If something else proves out to be useful we can host it. Not against this.
    • CW: best practices are written in a way that's agnostic of what the browser's doing. But maybe my perspective's Chromium based. Error handling doc - just had one screenshot from Chromium devtools. There's a giant MDN PR documenting WebGPU. In discussions with Chris Mills, didn't think best practices would be in MDN, since the WebGPU doc will already be massive. If this group decides it should be in MDN then we should check with the MDN folks too.
    • KG: already have indication that it's appreciated on MDN. You're welcome to double-check if you like.
    • MM: I'd be more comfortable with this information being in MDN rather than in our Github repos.
    • CW: there's a lot of value in hosting canon best practices somewhere.
    • BJ: specifically, other than some random person's web page (mine, right now 🙂)
    • MM: 2 reasons why MDN's preferable: web developers already look there, and in order for the best practices to be canon our group has to agree on them and that'd take up meeting time. I don't think we should spend time in meetings on this.
  • CW: would like to be more flexible in the ways we give things to developers. More than just samples and a pointer to the spec.
  • KG: meant to say - asking, is what specifically do we want to put in this org?
  • CW: specifically, types, best practices (linked above), helper libraries like mipmap generation, packing uniforms in javascript, and a couple others. The group's said, this isn't our problem in the spec - but we should provide an example.
  • MOD: (in chat) (texture loading transcoding helper would also be a great general tool)
  • GT: I think we shouldn't canonize these - why should mine be official and yours not? Deprecate the official one if someone else starts doing it better? WebGL has a wiki. Most web specs don't.
  • KG: If we want to entertain specific proposals to add things here, think we should do it on a case-by-case basis.
  • MM: Don’t see a distinction why the webgpu-native org can’t be the home for bindings. It’s an existence proof that these things can happen elsewhere.
  • CW:
  • MM: Software libraries also not in scope.
  • KR: We have experience in trying to maintain the WebGL proliferation of awesome libraries on the wiki. It didn’t really scale, and we had to turn off edit access for spam. But it was extraordinarily valuable to have a central place for … community and canonical information and libraries. Would like this group to have a lighter weight process for github.com/webgpu. Don’t personally want to have to come to this CG meeting every time we want to put something there. Don’t see a problem with trusting the community group members to add content and repositories to that org.
  • KG: My goal isn’t to put things in github.com/webgpu but to help developers find things. I think MDN is a better place for that, until we find something that doesn’t belong in MDN.
  • KR: Already have code helpers that belong on github and could go in this repository.
  • KR: Can we agree to put the types repository in there? https://github.com/gpuweb/types
  • KG: …
  • CW: Re the concern about using this group’s time on deciding what goes in this org, then let’s have a different group for it.
  • MM: what's the reason to not publish the types under github.com/google?
  • BJ: they're not Google types. They're TypeScript types for the WebGPU API. You could argue a couple places for them to go, but though Google's been maintaining them it doesn't seem appropriate to scope them to Google.
  • GT: I'd expect the types to be merged into the standard types. Wouldn't expect it to be separate.
  • KN: don't want to worry about the types for that reason. Expect those to be merged into TypeScript types.
  • BJ: TS is conservative. Not worried - they'll migrate them.
  • KN: so I wouldn't worry about them too much, but would like to move them so the url matches the npm package name (@webgpu/types)
  • KR: WebGPU debugger is next up.
  • MM: it's written by an organization. Should be in that organization's org.
  • CW: github.com/webgpu has no connection to a particular org. It's owned by the community and the community group.
  • BJ: thinking beyond this - everyone should have an idea of what the webgpu org is appropriate for. Everyone seems to have reasons why things shouldn't go in there. So if you could formulate suggestions for what should go in that would be helpful.
  • KG: Conversely want to focus on what value we can bring to developers using this org.
  • KR: At a minimum it’s useful as a central place for developers to find useful stuff for WebGPU.
• WebGL+WebGPU meetup at GDC March 22
  • KR: Evening of March 22nd, in San Francisco (during GDC). If you're in the area it would be great if you could attend, please let Ken know. Lots of cool presentations lined up and 100+ attendees expected. Will be livestreamed.
  • KR: No signup link yet but see email to [email protected]. Will send out the signup link when available but
  • KR: Hosting at a Google building, need registration from all attendees, and proof of COVID-19 vaccination.

CTS Update

• KN: working on it. 🙂

“Tacit Resolution” Queue

• Specify behavior of onSubmittedWorkDone/mapAsync on device loss #3937
  • KN: proposal: onSubmittedWorkDone resolves successfully. After device loss, keeps pretending it's working. mapAsync rejects the promise though. Might change in the future, but for V1, best to reject.

add query for list of WGSL software extensions #3875

• "Sugar features"
• BJ: seems not supposed to be different between adapters. Having to query these from the adapter doesn't seem that useful. Kai suggested putting this on navigator.gpu. Fine place to put them if we need them there. (JB gives thumbs up.) If they need to see them before creating the device, seems like a good place for them to live. Otherwise, having something on the device after you create it - want to see both the things enabled by default, and the things explicitly enabled as WGSL extensions, through features, in the same array. Single place to look for this.
• KN: think there's a value in having this be checkable before creating the device. App probably won't run if the sugar features aren't available. A choice people make ahead-of-time.
• BJ: only reasonable choice - I'll block you from running my app entirely - if you're willing to rewrite the shaders to not use the sugar, ...
• CW: sounds good on navigator.
• BJ: no strong concerns.
• JB: OK with having it on navigator. Wanted this as a help for the CTS. It can know what's expected to work and not work. E.g., full-powered pointers, later.
• MM: do you mean navigator.gpu?
• BJ: yes. Alongside preferred canvas format.
• MM: no concrete feedback. The API has limits, extensions, and now this 3rd thing. The shader language has hardware-dependent features and sugar features. So that’s 5 different … things, which seems overengineered to us. A little dissatisfied with this. We won't stand in the way, but wondering if this can be done better.
• CW: more proposals help here. WGSL doesn't have sugar features yet. Have time to iterate.
• KN: I don't see this as 5 things. We have shader/API sides - 2 things, but really the same. Just 3 things, don't think we can have fewer. Think we need these facilities on both sides. Interested in proposals.
• CW: for milestone 2?
• BC: there's value in end users checking for sugar features. Not just for the CTS. Checking for this is more difficult if you don't have the query mechanism in the first version. Happy with an empty array in V1, but want it spec'd.
• MOD: (in chat) (but "requires" in WGSL already sets the framework for v1 in source even if there are not any software extensions yet)
• KN: ok, we'll leave it in V1 for now.

Who actually wants multiple timestampWrites with the same TimestampWrite.location? #3808

• MM: discussed a few weeks ago. Group resolved on either of my earlier proposals. Pick the one most expressive. Found only 1's implementable, so that's the one that should be in the spec.
• KG: there's a PR for this?
• KN: yes.
• MM: so this is in accordance with the previous resolution.
• KN: would like some docs recorded about why it didn't work in Metal, so we know why we did what we did.
• MM: de facto, only one of the proposals worked on the devices where support was needed.
• KG: PR is #3930.
• KN: Editors to handle bikeshedding and land #3930.

Fingerprinting Surface #3101

• CW: Kelsey answered with current state of things and group's opinion. Talking about 32 buckets, people asked questions about how they're defined. Tried to answer. If you're interested in this topic, please chime in.
• KG: think your answer was good. There's a PR open for this. As resolved, we can close that PR?
• https://github.com/gpuweb/gpuweb/pull/3840
• CW: I think we can merge it.
• KN: +1
• KN: There was an editorial fix if you (or I) can fix it.

Adapters should not be allowed to expose contradictory workgroup size limits #3888

• CW: extends to other limits too. A bunch of limits which intersect each other. What do we do?
• KN: we already have several of these in place like maxStorageBufferBindingSize (?). Question is compute side, workgroup sizes. Other places that could use similar restrictions? More trivial ones left.
• KG: I'd rather not spend 4 lines making these requirements. But if you really want it to be so, we can have them.
• KN: fair position. I like having them - app wants to take a limit from the device and use it. They'll run up against it, and I don't want them to trivially run up against another limit as a result. Don't want them to write that logic and go to another browser with different limits and have it break.
• Discussion about whether these tests are useful.
• E.g. maxStorageBufferBindingSize <= maxBufferSize. This test already exists.
• KN: For example, an application takes maxStorageBufferBindingSize and make a buffer of that size. Can't because maxBufferSize is smaller.
• CW:
• KR: I thought the statement was if they’re in the spec, then we can write tests for them.
• CW: We can write tests which technically aren’t in the spec as additional guides for implementations.
• KG: whatever you'd like to do in this area is fine by me, with my previous recommendations against this recorded above.

depthWriteEnabled and depthCompare are required even for stencil-only formats #3905

• CW: not helpful for developers.
• KN: rare enough case that I don't care about this for V1, but wanted it documented.
• KG: +1
• MM: what's the reason to not have the default?
• KN: in the stencil only case or generally?
• MM: stencil.
• KN: makes an optional boolean. tri-state thing, annoying for implementations. Would rather deal with this later.
• MM: think optional seems straightforward. Benefits seem to outweigh the costs.
• KG: I think if you want a proposal, you should make one. I think otherwise we’re fine for V1.
• KN: part of complexity - two possibilities. It's either regular validation, or make it a JS exception so impls don't need to wire the tri-state through.
• CW:
• KG: if no proposal, can leave this incomplete for v1
• KR: If these are required in the WebIDL and you didn’t provide them, that would be a JS exception. So I think the closer we can get to that behavior the better.
• KN: Different from how we do most validation.
• CW: would like to propose we fix this in Milestone 2.
• KG: agreed, would like to not do anything right now.
• MM: I'm willing to make a concrete proposal.
• KG: take an AI. 🙂

Limit for the maximum resource size? #3916

Agenda for next meeting

• Limit for the maximum resource size? #3916
• maxVertexBuffer + Bind Groups limit - agreed we could unbind things - some complexity in the Web IDL.