Minutes 2023 04 12

GPU Web 2023-04-12 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
• CTS Update
• “Tacit Resolution” Queue
  • Make lost devices appear to function as much as possible #1629
• Standard Sample Pattern #4005
• Validation and behavior of alpha-to-coverage #3982
• Remove validation of maxFragmentCombinedOutputResources? #4018
• Default value of maxBindGroupsPlusVertexBuffers #3938 (comment)
• requestAdapterInfo() should be required to prompt (in at least some circumstances) #3962
• Agenda for next meeting

Attendance

• Apple
  • Mike Wyrzykowski
• Google
  • Ben Clayton
  • Brandon Jones
  • Corentin Wallez
  • Gregg Tavares
  • Kai Ninomiya
  • Ken Russell
• Mozilla
  • Kelsey Gilbert
  • Teodor Tanasoaia
• Nvidia
  • Anders Leino

Administrivia

• KN: NVIDIA is here! Welcome!
• AL: Hello. 🙂

CTS Update

• KG: working on some blockers that will allow us to write CTS tests. You should start seeing more contributions from Mozilla.
• KN: exciting.
• KR: also - weekly reminder - contributions welcome to the CTS!
• KG: almost there for Mozilla!

“Tacit Resolution” Queue

• Make lost devices appear to function as much as possible #1629
  • KN(pretyped): For the remaining issues, having worked through all of the options we could think of, the editors recommend the following behaviors for operations that finish after device loss:
    • Change popErrorScope() to return null regardless of any validation (instead of rejecting if the device is lost).
    • create*PipelineAsync should pretend to work, even with a bogus descriptor. In this particular case, it would be just like the non-async versions: it returns an internally-invalid pipeline (/de facto unusable because the device is lost), and no error is reported because all error reporting mechanisms are cut off after device loss.
  • Editors spent a lot of time discussing this the past couple of meetings.
  • CW: seems good.
  • Tacitly resolved!
  • KN: concerns? Just make them known the next couple of days.

Standard Sample Pattern #4005

• KN(pretyped): investigation shows we can now support the standard multisample patterns on all backends, thanks to having dropped macOS 10.12 support
• KG: let's take it!
• CW: did you look at the Vulkan feature?
• KN: yes, it's on every device. We knew this from the beginning: basically 0 devices on GPUinfo.org that don't have it.

Validation and behavior of alpha-to-coverage #3982

• KN(pretyped): Last outstanding possible new validation for V1
• KN: more investigation needed. Shrek discovered a few things writing alpha-to-coverage tests. Very useful.
• Think safe thing for now - can't use alpha-to-coverage if you don't have a texture attached to attachment 0 with an alpha channel. More strict than theoretically needed - all you theoretically need is an alpha value. Metal - anything you write to alpha seems to get dropped on the floor if there's no texture there. Would need to work around this, or declare it's the standard behavior, or just validate it. Without knowing details - have stricter validation now, investigate more later on. Maybe can have the stricter validation indefinitely?
• KN: proposal: if you enable alpha-to-coverage, you must have an attachment 0 texture with an alpha channel.
• CW: probably OK.
• KG: what's the proposal?
• KN: add validation - render pipeline creation's illegal if you try to enable this without an attached texture with alpha.
• KG: sounds reasonable. If you don't have this, hard to calculate this accurately. Is it observable?
• KN: there should be behavior difference without this. Some backends - if you don't output alpha, validation error (not sure). On Metal - even if you output alpha value, if no attachment - assumes it was 1. Sounds like a bug. 3rd behavior - can take alpha value from fragment shader and use it for alpha-to-coverage even if there was no texture with an alpha attachment.
• KG: so you have an attachment 2 and no attachment 0, problems?
• KN: yes. Or you do a depth prepass for example.
• KG: contentious? Couldn't do a depth prepass.
• KN: with a2c, yes. Probably want to reduce these restrictions later, but don't know yet what we can do. Could do the investigation, but will take time. Pretty complicated.
• KG: functionality we'd lose - you can't do a pure depth prepass with a2c.
• CW: seems fairly minor, almost application bug if you do this.
• KN: not sure - could be useful, but don't know enough about how applications use things.
• CW: we can add the validation to start. Worst case, if we really need to support this, can implement a2c inside the shader, either at ShaderModule or pipeline compilation time.
• KN: think we can do this - needs more thought. Just a matter of what we can do.
• CW: resolution - add the validation you suggest. We have validation in several places - needs to be made more flexible down the line, but don't have time, so consider it post-V1 polish.
• (More discussion)
• KG: just need to keep this at the front of our minds - represents a functionality regression compared to WebGL.
• KN: yes, that's an important concern.
• CW: are we still OK with adding validation, and re-investigating soon?
• KG: yes.

Remove validation of maxFragmentCombinedOutputResources? #4018

• KN (pretyped): New info that this limit is also incorrectly reported on PowerVR, further validation that it’s . Question whether we should remove this for V1.
• KG: just the validation? Stuck with this limit?
• KN: think Chrome's willing to unship this limit completely. The proposal's to remove it completely.
• KN: 4 of our 6 vendors incorrectly report this limit. ARM correctly reports it, but it's not meaningful on those devices. It's just Qualcomm. On GPUInfo, the limits are high enough that we can just allocate the other 3 limits within it. Only for older Qualcomm devices - just a legacy thing.
• CW: let's remove it, and we'll figure out how to unship it from Chrome.

Default value of maxBindGroupsPlusVertexBuffers #3938 (comment)

• KN: haven't figured out what base limit should be. Bind groups is 4, VBs is 8 - but real limits will be higher. If set to 12 by default, have to worry about it when you raise either of the other two limits. Make it higher? 24? Max BG=8 and VB=16 are pretty common values. Won't run into it for a lot of default configs.
• KN: theoretical value's 29. Only exists on Metal. Limit of 31. 1 UB reserved for the impl, and one other thing. Weird to push this value out all the way.
• CW: sounds good. # devs asking for more than these is limited.
• KN: yes. Also possible to raise the limit, but want 99% of developers to not have to think about this limit.
• KG: it's interesting - can make different tradeoffs at different times.
• KN: that's the thought behind the limit. A limit that likely only Apple will take advantage of. Not sure about Firefox. Chrome won't take advantage of it.
• KG: 24 sounds fine to me.
• MW: 24 should be fine.
• CW: resolved - limit raised to 24.

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

• MW: talked with Myles. Our consensus, we don't have to push so hard on the prompting. Could also push this out.
• KR: our concrete proposal - remove unmaskHints, and remove the need for the prompt.
• MW: we're probably OK with this but would like to push out a week.

webgpu org disposition

• KR: there were some strong feelings about this internally - resolved with the idea that we'd explicitly banner this as "Not an official product of the WebGPU CG". How does that sit with others?
• KG: most core request in my mind - because of the ownership model and the appearance of things, even with a banner across the top it could be considered semi-official.
• CW: what if it's not run by us? Can imagine there are people in the WebGL community space who are elder community members.
• KG: what worries me - we want to have oversight as member companies. Think we shouldn't just throw "everything" in there. Part of what people are afraid of - having to come to the group and say, I want this included, and the group says no. If it's called webgpu.org and owned/run by people who are in the WebGPU group - think we need to be able to say no. Maybe wouldn't often say no.
• KN: that's why we're worried. Think the group would say no to most things. When discussing specific things, we'd say we don't want libraries or links to libraries there. Right now only have the samples and the debugger, and it sounds like not everyone agreed with the debugger. Concern with that model is that it'll be used a lot.
• BJ: other thing discussed - documentation in the form of best practices. Concern is, whose best practices do those represent?
• KG: that's the single biggest thing that members of this group need sign-off over. That's a hard line, need this sort of collaboration, but historically this hasn't been a problem. Have historically had best practices for WebGL, put it on MDN, without a lot of trouble.
• CW: if people here think best practices should go on MDN, we can do that.
• BJ: yup.
• CW: note, we spent an inordinate amount of time getting WebGPU guide on MDN with Chris Mill. Lot of things Chris asked about, Chrome-specific behavior - we said no, here's the spec. I think it'd be surprising for people to review the PRs for MDN - almost seems that this group doesn't have a say.
• KG: people who maintain standards-conformant browsers are core stakeholders of the MDN docs.
• KG: don't think you should be worried about things being held back because people need to say no to them. I don't remember being pinged about best practices for WebGPU.
• CW: they're published under Brandon's Github right now. If we say MDN is the place, we can move them.
• KG: would want to review, do these all make sense? Similar to WebGL. We developed the WebGL ones in my HackMD. Collaborative editing effort. Then we moved it to MDN.
• CW: this is fine. Here we're talking about docs/best-practices for non-browser part of WebGPU. There's a lot of things that webgpu.org or the WebGPU Github org could host. webgpu.org should also point to the MDN docs, etc. Could webgpu.org also point to more things? Some of the info out there's already outdated.
• KN: one example devs would want on webgpu.org is native stuff. This group might not approve that. Would be good to have pointers to docs on native, how to use Emscripten, wgpu, etc.
• GT: seems to all come down to the name. I just registered webgpuinfo.org. If the 10 people who want webgpu.org move over there, seems fine. Is the name special? Could put all the info on a different website. To me, I'd be happy if the name were given to the people who'd manage the site regardless.
• CW: let's say we use webgpu.graphics. Don't know the status of that domain name. The people who'd likely contribute to that would be the same contributing to webgpu.org. What's the difference between this and a webgpu.org?
• KG: we want a website that serves as a nexus to direct people, and creating a community around it. If you want that, seems like something the group has an interest in.
• CW: if there's a website where people individually at Google are interested in it - look at Brandon's work, Gregg's, the debugger, etc. - interested in helping the community. Of course we'll try to link to the best resources out there. Would like to do this collaboratively with everyone. If there's a site to try to build this nexus - of course CG wants some oversight over it. Because the group wants oversight, every contribution's more risky. Harder to get things in because everything has to be reviewed. Loses value. How do we solve this? Would be really nice that this group has veto power over but looks at it from afar. Can even ask the WebGPU community - non-implementers, non-IHVs - to participate. People are excited and want to contribute resources.
• KR: concretely - how about a few interested CG folks be co-owners of the github.com/webgpu org (I think this is already the case), banner it as non-official, and bring in more interested community members as co-owners and co-maintainers?
• CW: or how about - this is not official, and some people can have veto power, but it's not the WebGPU CG?
• KG: want to hear assent from other members here about that plan. Think it might be tolerable. The way you describe it, think we should understand the politics of it - it'll really be an official thing, but is branded as not being. Just want that understood.
• MW: would need to discuss more with Myles.
• CW: that's OK, won't be resolved in a few meetings. Governance discussion, these take time.
• CW: even if this is marked unofficial - can be spawned from this group. We can spawn it with its own governance / guidelines, if we want to. As simple as we want, and as complex as we want.
• KG: that's sort of why I don't want to spin it out, think it'd be more complicated. Then need some idea of governance that isn't part of the CG.

Agenda for next meeting

• Unmask hints
• Running out of V1 items - this is good!
• Ready to start looking at low-hanging post-V1 things? Or wait a little bit for impls to catch up?
  • KG: think we should entertain post-V1 topics, and mention if we're not comfortable discussing them yet.
• CW: good. I set up Milestone 2 in the Github project. If stuff you'd like to discuss, please drop in milestone 2. Want to do this for WGSL too.
  • Try to not add the whole world. No raytracing please. :)
• KG: mesh shaders? They're on Metal now.