-
Notifications
You must be signed in to change notification settings - Fork 304
Minutes 2022 03 09
Corentin Wallez edited this page Mar 15, 2022
·
1 revision
Chair: KG
Scribe: KN/KG
Location: Google Meet
Previous meeting:
- [Process] Extensions directory in gpuweb/gpuweb #2301
- [Process] Requirements for additional functionality #2424
- Allow unmasked adapter info fields to be requested individually. #2635
- Add rg11b10ufloat as valid render attachment format · Issue #2648
- Streaming implementations and indirect draws/dispatches #2189
- Cannot upload/download to UMA storage buffer without an unnecessary copy and unnecessary memory use #2388
- Apple
- Myles C. Maxfield
- Google
- Austin Eng
- Brandon Jones
- Kai Ninomiya
- Microsoft
- Rafael Cintron
- Mozilla
- Jim Blandy
- Kelsey Gilbert
- Unity
- Brendan Duncan
- Michael Shannon
- KN: Lots of stuff going on. Someone made stats for it! Good progress.
- MM: I sent an email out about CTS integration into “layout tests”
- MM: I think I see a reasonable way to integrate it, but if there’s a blessed way to do it, that is less likely to break, then we’d love to use that instead.
“Tacit Resolution” Queue
- KN: While we really would have liked to have this in, I don’t think we can invest into getting this in at this point. We’re continuing to work through multithreading design issues, and that we should be able to handle them, but not in v1.
- Tacit approval, needs spec.
- ** KN: I’ll close this, and if anyone wants to do something different, do so.**
[Process] Extensions directory in gpuweb/gpuweb #2301
- MM: One thought, we (the community group) decided not to ship pipeline statistics in v1, though we didn’t further say that we would never add it to the spec. If we do think something will never make it into the spec, we probably shouldn’t put it in our repo.
- KN: My premise was “this is not on our roadmap”, but I think this is on a sliding scale. It’s not on our roadmap unless someone comes to us and asks for it. Probably a 50/50 chance at this point.
- MM: I think 50/50 is a good guess. I am only pushing back on things we are pretty sure never will be spec’d. (E.g. we might decide, “we’ll never add Tesselation”, in which case we’d delete the document from this Organization, at least.)
- KN: I can propose wording to describe when things would end up in here, and when not.
- MM: What I’m really worried about here, is having to make a WEBKIT_ extension, having to put it in this folder, and tell people “I know this isn’t part of the spec, buuut…”
- KG: For me, I really want it clear than the contents of this directory aren’t normative. Maybe to the point of naming/nesting the directory
/non-normative/extensions. - MM: Want to think of it as a staging ground, if we know it’s not going to end up in the spec, it shouldn’t be here
- KN: Think that works for us, though don’t remember all the things we were thinking about putting in this directory.
- overall agreement, KN to adjust language in PR
[Process] Requirements for additional functionality #2424
- MM: I think there’s general CG agreement about hte philosophy here. There were some concerns, but I think with some clarifications/fix-ups, I think we’ll be in a good place.
- KG: Left comment, but think this is a good recitation of our operating principles. My weird point - maybe shouldn’t worry about it - is that writing down rules can cajole people into wanting to finagle what they want within those rules. But actually think that’s not a good reason to not write things down, people of middling faith will do things of middling faith anyway.
- MM: In this particular case, 3d graphics has a lot of people coming from different contexts with different ideas, think it’s valuable to write this down even if we’re all abiding by the principles today.
- Google to review
- BJ: (summary), also some other minor changes.
- BJ: Right now, says if you request something that the UA doesn’t want to provide, it rejects the promise. Unsure if that fits with the ethos of what we’re trying to achieve.
- MM: Think you did everything I described last time we discussed. One thing I was surprised by was iframe allow=webgpu, which is a little scary because we might want to disallow webgpu in iframe regardless of whether the parent page wants to allow it.
- BJ: Reasonable, figured I’d highlight another privacy-centric tool here, but technically distinct so could move forward with just the identifiers portion of this and continue to discuss whether or not we want to use the permissions API for iframe control.
- KG: Where is this mentioned?
- BJ: Not in this PR, but in the document already: using permissions API to add new values that can block an iframe from using WebGPU. Becoming more common to control things like WebXR, Web Audio, etc. Way of embedding content without allowing capabilities.
- https://github.com/gpuweb/gpuweb/blob/adapter-identifiers-refactor/design/AdapterIdentifiers.md
- BJ: Included because also falls under the privacy umbrella.
- MM: Not pushing back on the idea, just not very familiar with the attribute. Does allow=webgpu mean you must allow WebGPU or does it allow the browser to still deny it?
- BJ: Completely reasonable to discuss/learn about this separately.
- MM: On rejecting: Probably good, encourages authors to only request what they need, make it slightly painful to request all info.
- BJ: Want to do some reading to learn why that decision was made in the getHighEntropyAPIs. Seems that providing a rejection provides more information than just null/undefined - ambiguous which of [UA doesn’t know, UA doesn’t expose, user chose not to expose, etc.]. So want to see why they did it this way.
- MM: The promise may also be hiding a prompt. UAs try to avoid making prompts. So if there’s a rejection and then the page requests less info, it might get auto rejected so the UA doesn’t have to ask again.
- BJ: Reasonable to iterate further…. If no concerns about this PR to the design doc, would like to merge it and then put together PRs about how it would be integrated into the spec. Any concern?
- KG: Rejecting seems more fragile than just returning less info. Useful because most of the codepaths keep working. Rejecting has to be handled explicitly. In a world where there’s an app that works in a common browser and doesn’t care about others, they may well break in other browsers.
- BJ: …
- KN/KG: Likely best to ALWAYS provide strings (no null/undefined), for that issue. Then all of the string prototypes are present.
- BJ: Only thing it may cause confusion with is if the driver returns an empty string or something. Don’t know if it’s ever important to distinguish that from “I didn’t want to tell you an answer”. Only place where it seems preferable.
- KG: Approved PR
- MM: KG, would prefer never to reject, instead return empty GPUAdapterInfo?
- KG: Basically yes. Think key thing this is valuable for, is to leave us room to ask the user for permission. That’s the big winner. And allow asking for specific things. As UAs probably wouldn’t be able to actually prompt at this granularity, but this API design allows us the opportunity to try.
- BJ: Agree the important part is the opportunity. Also allows UAs to decide where their cutoffs are. What they would expose always, behind a prompt, never.
- BJ: Myles, you’ve said you would never expose anything. Would Apple ever feel comfortable providing values with user consent?
- MM: Our general philosophy is that it’s very hard to get informed consent from users via a prompt. But that’s part of our browser product, not my call.
- KN: What we can do with this info, is use it to group this request to say e.g. “this page wants to identify you within a group of about NNN individuals”. Something like that.
- KG: Think we have things to move forward here.
- KN: Basically Adreno 500.
- KG: Polyfill/emulate it in core. Maybe add this to core after 1.0.
- MM: Emulate the reduced precision?
- KG: Probably not
- KN: I’d probably actually have an rg11b10 texture underneath, copy into it from a temporary render target.
- RC: Think in the past we’ve gotten in trouble trying to emulate formats, especially expanding compressed textures.
- MM: Maybe we shouldn’t polyfill it if users would want to know it’s polyfilled.
- MS: This would be memory magically created behind the scenes that we don’t know about, on already memory-constrained devices.
- KG: Think it’s worth including because such a large majority would benefit from it. Think the subset is getting small enough that it’s worth the tradeoff. Since it’s so widely beneficial, would like to put it in core, and polyfill it to increase the reach.
- MM: If I’m a developer, under what situation would I use this format? Sure nice if my data fits into it, but when would I actually prefer it? I think it’s only when you’re memory constrained, otherwise can use a larger format. So think this is a point in favor of KG’s proposal.
- KG/KN/MM discussion: Adds implementation cost for 1.0 release on these devices, but can release on those devices later, probably fine.
- (KN: As long as we’re sure we can emulate it)
-
KG to write PR
- (posted: https://github.com/gpuweb/gpuweb/pull/2659 )
Streaming implementations and indirect draws/dispatches #2189
- MM: (Recap)
- KG: Reminds me of the optional barriers. Allow stating beforehand that you want to use it as an index buffer, before the render pass starts. However, if a user did get this wrong, we are back to where we are now: We might even have to throw out a partially-recorded command buffer.
- MM: Austin had a fairly genius idea (though not positive it will work yet) where before every render pass you execute an indirect dispatch. At the time you enqueue it, you don’t know what it’s going to do, but decide later during encoding of the render pass. Reason I’m not sure it will work is indirect command buffers for compute don’t exist on all Mac devices. So have to use indirect dispatches. Can I fit it into a predefined set of dispatches?
- (out of time, continue next time)