Skip to content

Minutes 2020 12 07

Jump to bottom
Corentin Wallez edited this page Mar 30, 2021 · 2 revisions

GPU Web 2020-12-07

Chair: Corentin

Scribe: Ken and Austin

Location: Google Meet

Tentative agenda

  • PR burndown
    • Add interface GPUAdapterLimits; GPUAdapter.limits #1273
    • Add shader-float16 extension #1275
  • Sparse colorAttachments #1250
  • Destroying pipelines #1263
  • Conversion when the format of input state does not match what's in the shader #1264
  • Post-comparison-filterable depth formats #1266
  • First WebGPU Stable Release / Prognosis ? #1276
  • (stretch) Multi-queue synchronization #1169
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
  • Google
    • Austin Eng
    • Ben Clayton
    • Brandon Jones
    • Corentin Wallez
    • Kai Ninomiya
    • Ken Russell
  • Intel
    • Yunchao He
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Dominic Cerisano
  • Mehmet Oguz Derin
  • Timo de Kort

Administrivia

  • CW: From now on we’ll use github wiki as our official place for meeting minutes (since Google docs is not universally accessible). We’ll still use gdocs to take the minutes and a script will convert it into the wiki.
  • DJ: can someone else chair 2nd half of WGSL meeting?
    • DM: I can.
    • DJ: I’ll send out the agenda.

PR burndown

  • Add interface GPUAdapterLimits; GPUAdapter.limits #1273
    • KN: I redid this, with various discussions in mind. We don’t want to design this around the privacy budget because that’s not final yet. This does the simple thing and exposes GPULimits on the adapter in the form of an interface. This makes the properties lazily computed. UA’s can still do bucketing across devices to reduce identifiability. Can even do so based on queries to the limit members. We keep the ability for apps to request a device without checking limits first. Apps don’t have to do a bunch of queries just because they want to create a device with some features available. Most straightforward edition of the change.
    • JG: thanks for writing this. Did you include a note that we’re going to treat unrecognized limit/feature names as if they violate that limit? Want to make sure we don’t accidentally ignore them.
    • KN: I left several issues in. In the device descriptor, we need to change features to be a sequence of strings instead of GPUFeatureName so idl doesn’t reject it. For limits, we need to change it from a dictionary to a record<DomString, any>. That’s left as a separate issue; didn’t want to do in this PR.
    • DJ :thanks for writing this. Sorry didn’t look at it earlier. Think this is OK. Apple’s position: we’ll wind up with buckets no matter what. Majority of developers will assume buckets. To think ahead: would be nice if (separate from spec) UAs could get together and discuss, maybe, where we tweak the limits to enable buckets so it’s easier for developers to find them without querying everything.
    • KN: So some way to make the limits/extensions more .. across different devices and UAs.
    • DJ: yes. As part of this we had some discussion with Metal ecosystem to figure out what they’re using the GPU families for. They don’t distinguish that much. Majority of game engines already do bucketing. They know they’re on an iPhone whatever. The engine doesn’t have 50 different branches. 2-3 at most.
    • KN: I think most will have at least two: desktop, mobile. But they might have high-end/low mobile.
    • DJ: yes. Embedded, whatever.
    • KN: Will have some paths that can be enabled/disabled in a more isolated way. They won’t be architected to ONLY use etc on mobile and ONLY bc formats on desktop. That’s a lot easier to separate out.
    • DJ: right. Point is, Apple might want to bucket their results, but wouldn’t want to do it in different way to FF, Edge, Chrome. API is fine as is, but should follow up with some sort of coordination.
    • KN: at API level makes sense to not think about it. Can’t design such a complicated problem yet.
    • CW: I’d like to note that ideally we should agree on the lowest-fingerprinting buckets, but there are going to be cases where we want to expose way more buckets - like when the page is more trusted for installed PWAs. We might give finer grained buckets there. I don’t think we should force that impls give only the buckets, just for good taste to use the agreed buckets for random web pages.
    • KR: Earlier in the CanvasRenderingContext discussions, there was a separate wiki page we linked to. Maybe we can do something similar and describe the buckets as they exist there. Would be nice to make tangible forward progress on this.
    • DJ: I agree that that’s a great way. Doesn’t need to be formal, just a wiki page. I’m happy to land this with the one request that I ping Myles first, and if we don’t hear back in 24 hours just land it.
    • RC: one question: it says it needs to be Record<DOMString> but is now an interface. Are we going to keep this as an interface?
    • DM: the Record is for the Dictionary. The interface will stay.
    • KN: the interface is for things coming out of the API. Going into the API, you currently use a Dictionary, but needs to become Record. Record can’t be returned, I think.
    • RC: ok, makes sense. I’m also OK with exposing it as we have it here.
    • DM: why does it need to be converted to a record?
    • KN: browser needs to be able to see names it doesn’t recognize. With Dictionaries you can’t see keys not defined by the dictionary IDL. I only read the Web IDL spec, but it says that coming in, the JS object is gone.
    • JG: that’s true if we make this into a real Dictionary. If we care a lot we can take into an Any.
    • KN: Web IDL has Records for this purpose exactly - to see all keys.
    • RC: Are we okay if I make a page, and then limits are added after, will my page stop working? Oh nevermind, it’s only if I use a limit that isn’t supported.
    • DM: is it the same thing on user’s side? They make regular JS object, pass it in, and Web IDL sees it as a record?
    • KN: it’s just a different conversion. Set of (key,value) pairs.
    • JG: conditional approval on not hearing anything negative back from Myles.
  • Add shader-float16 extension #1275
    • CW: Adds the name and a line about what it does. There’s several ongoing questions that happened after the agenda. Maybe we can skip this and make more progress offline. What do we want to see on this PR to accept/reject?
    • JG: David had great questions; I’d like to see most answered at least non-normatively. Right now I’m not sure what adding float16 even does to the WGSL API. What form does that take? Good to see the basis for that, don’t need everything.
    • CW: Okay a little bit of grammar, addition of a type, etc?
    • JG: yes.
    • DM: we need the investigation, as David noted. What does this do? Then, the grammar.
    • CW: I don’t know if Intel Shanghai will be able to do the investigation.
    • JG: the investigation or the grammar?
    • CW: the investigation.
    • JG: one way forward: pick subset that’s most useful, do just that investigation. Vk does this 12 different ways. Only picking load/store, for example. Quick investigation on those.
    • CW: agree. Don’t need investigation on arithmetic and error bounds.
    • JG: agree. Think that’s not necessary from David’s request. May be useful to attach this to WGSL meeting agenda. Want to hear David’s direct input.
    • CW: aside from extension name, this is mostly a WGSL thing. Need more input from WGSL TSG subgroup.
    • DM: are there vertex formats with 16-bit floats too?
    • CW: don’t think that was the intent.
    • DM: ok. Make sure that’s included in the investigation.
    • JG: I’ll look into that too.
    • YH: Xinghua’s discussed the format issue internally, but not sure they did comprehensive investigation.

Sparse colorAttachments #1250

  • CW: Babylon.js ran into this. Spec currently doesn’t allow this. Every API we target allows sparse color attachments.
  • KN: We talked about this a long time ago; I thought we were going to have it but forgot about it.
  • JG: +1. Felt uneasy about the syntax we needed in web IDL to do nullable arrays. To move forward we made them compact for the time being.
  • KN: that’s what I remember too.
  • CW: Okay so it seems we all want them, how do we make the API happen? Arrays of nullable?
  • KN: not sure. Be consistent w.r.t. bind groups. Arrays of dictionaries (?) that have binding entry.
  • JG: it’s not nullable but you have to give it a trash descriptor?
  • KN: No you’d just say: [{attachment: 0}, {attachment: 2]. This is how bind groups work too and would be consistent.
  • CW: vertex buffer layout descriptor - vertex buffers don’t work like that.
  • KN: right.
  • DM: We are talking about the sparse GPUColorState descriptors?
  • CW: sparse GpuColorState descriptor, or sparse renderpass color descriptor, sparse array for the render bundle descriptor color format.
  • DM: Okay so this is two similar but different issues. One is sparse render pass attachment and one is sparse render pipeline attachment.
  • KN: in principle I think we can solve these at the same time.
  • CW: I think they can just be nullable. It’s something we already have in the vertex state descriptor. There’s a sequence of nullable vertex buffer layout descriptors. We can do the same for color state and render pass color attachments. It’s nice in the simple case and ok in the sparse case.
  • JG: I wouldn’t make any changes to unrelated sections in this PR, but this sounds like a good direction for this PR, and we can talk about renormalizing other areas of the spec in a separate PR.
  • KN: The only other one that diverges is the bind group and bind group layout entries.
  • CW: I think the biggest difference is that color attachments and vertex buffers, there’s a limit on how many you can have. 4 color attachments, 8 vertex buffers. Binding number can be anything.
  • KN: I think that’s an important difference.
  • CW: let’s say - yes, we want this. Probably with arrays of nullable stuff. Need to see PR with spec change.
  • JG: I’d approve that.
  • DM: seems fine, tentatively.
  • CW: need spec PR, so there’ll be a second round of API review.
  • KN: Need to change render pass descriptor, render pipeline descriptor, render bundle descriptor.

Destroying pipelines #1263

  • CW: Jesper was looking at various destroy methods (buffer, texture) and was wondering whether there should be one for pipelines too. Need to check the destroy state on each submit.
  • DM: I think it’s fine to postpone.
  • JG: I’d just close this issue. Unless it comes up as another issue we can reopen it, but if there’s not high memory or other cost from keeping it alive, just GC it.
  • KN: If there is a high cost, then implementations might be able to convince their GC that is has high cost and GC it earlier. We explicitly decided a long time ago to just let these things be GC’ed.

Conversion when the format of input state does not match what's in the shader #1264

  • CW: basically have 3 types of vertex formats: uint, int, float. Normalized int == float. What happens / is it allowed if in the shader you declare “float” and in pipeline state “uint”? And vice versa.
  • DM: Lot of extra work for us and I don’t think people really need it.
  • CW: is it well defined in every API?
  • DM: no, it’s invalid in the APIs. Have to modify the shader to make it valid for the APIs. What they want is not in the APIs. You’re creating a pipeline so you can modify it in a lot of different ways. We could do this, but I don’t think we should.
  • JG: +1 to not do it.
  • CW: OK, I got confused. Thought WebGL was doing this.
  • JG: The way it works in WebGL is that there are three “types”. Floatish, int, and uint. If you have something like uint and you pass normalized: true to vertexAttributePointer, it’s a float. That will decode it as a normalized integer, but not an implicit conversion.
  • KN: thought there were implicit conversions, but might be thinking about uniforms. Float in shader, but can feed in integer, converted to float for you.
  • JG: I think maybe, but for vertex formats it’s pretty clear.
  • KR: Pretty sure we saw driver bugs in this vertex attribute code. Hopefully they’ve all been fixed, but I’m strongly in favor of keeping the API simple.
  • DM: We have the normalized ones, we don’t have the non-normalized ones. That’s what the author wants IIUC.
  • CW: Yes, the author wanted non-normalized int to float.
  • KR: Let’s just say no.
  • CW: it’s not in Vulkan. Base type of format must match base type of input in shader.
  • JG: Yea it’s the base type they’re talking about.
  • CW: we can close as WontFix, none of the APIs do it.
  • JG: I’ll write this.

Post-comparison-filterable depth formats #1266

  • CW: let’s skip this so we can talk about #1276.

First WebGPU Stable Release / Prognosis ? #1276

  • CW: would like this group to talk a bit more about timelines. We should feel pressure to ship. I said this a while ago, but even more so today - working group was started almost 4 years ago, unlocked shading language this year. People need this in order to do stuff on the web. In Chromium we have some unnamed partners who are really eager to use the API in the wild.
  • CW: also want to talk about aggressively deferring stuff post-MVP.
  • CW: in Chromium we’d like to make an Origin Trial first half of 2021. That will sort of be considered MVP - we expect the API will change, and will tell users about this. Would like to ship a V1 of the API next year, presumably end of next year. On API side think we’re almost there. Details to be filled out. In the spirit of shipping quickly, would like us to defer / prioritize heavily what we discuss. Multi-queue is probably not needed in V1 of the spec. Should think about it to make sure the spec can accommodate it.
  • JG: actually think MQ is a key feature. Something people can’t do in WebGL.
  • KR: We also don’t have compute in WebGL. Getting some compute in the hands of users is super important.
  • JG: I agree; I think the fundamental disagreement is how long MQ will take to get out the door. Don’t think it adds that much more time. Don’t want a case where making design decisions intuitively has us end up with two ways to do MQ in the future.
  • CW: I can take an AI to try to list all the things that MQ would interact with, and come up with proposals for some of them. Hopefully then we can discuss these areas and make the forward looking decisions. Second: we have different estimates of how long discussions will take. Maybe say, let’s timebox these discussions. 2-3 meetings. If it goes past this, then it was a complicated topic after all.
  • KR: +1. Some of the spec discussions for gone on for a quite long time and there’s a large backlog of issues. Would be good to drive them down and get spec changes in. Having interminable conversations is something this CG could improve on.
  • DC: For MQ, for the MVP, would it be useful to look at it in terms of use cases and pick one that it could fulfill to start? Instead of designing a minimal version of everything. I would suggest that use case be async compute.
    • CW: That makes sense. I’m worried that some of the difficult things we have to talk about are concurrent access to the same resource on multiple queues.
    • DC: if you did async compute then the synchronization is the empty graph. It’s a use case which is included in MQ. Pretty basic one. The resources are separate.
    • KN: that’s not what async means.
    • CW: async compute - when Doom 2016 and others talk about it - that’s not what they mean.
    • KN: it’s not valuable to do MQ without sync because you could just do that with separate devices.
    • DC: I’m saying it’s a use case for MQ.
    • KN: it’s not.
    • DC: it’s one that could be done for MVP.
    • CW: we should discuss this offline. We’ve had this discussion several times. We’re always hitting the same thing right now.
  • CW: We should prioritize what efforts we start to make sure they solve needs the first WebGPU users will have. We all want RT, but it’s not something people will need on day 1.
  • JG: in particular, ray tracing / mesh shaders are things everyone tacked on to their APIs. Don’t have to worry about backward compatibility.
  • CW: first thing to ask: what does this group think of the timelines? And what do you all think of, with the exception of maybe MQ, decide that the API we have right now in terms of GPU features is probably enough? Probably things we need to discuss in terms of DOM interactions. But in terms of GPU features, probably enough for V1.
  • DM: From our side, I think we’re not going to be ready to ship a V1 release next year. But could be in a state to approve an API of V1 form next year.
  • CW: OK, that’s really encouraging. I was going to ask you Dean what you thought?
  • DJ: I agree with what DM said. I want to ship something next year, and am happy to cut things out to get to that point.
  • CW: that’s super encouraging. Let’s prioritize so that we can make that happen. Let’s not spend another 3 years making a first version. Figure out a process where we can easily say something goes for post-V1 at this point.
  • CW: hopefully likewise for WGSL. Internally, Brandon just sent an email with experience from WGSL. Lot of nice things the language could help developers with. Likewise, probably not needed for V1.
  • DC: Q2 2021, is that still a thing?
  • CW: that’s what we’re aiming for Origin Trial.
  • DC: in use in browsers?
  • JG: no, only behind flags, or on a site that has the Origin Trial.
  • CW: the way Origin Trials work, web sites can register to get a key per origin, that lets them use the Beta version of WebGPU that is guaranteed to break.
  • JG: how easy is it to get an Origin Trial key? Could I get that?
  • CW: yes.
  • https://github.com/GoogleChrome/OriginTrials
  • JG: most APIs aren’t this sophisticated and this hard to chagne.
  • CW: the reason we’re doing this is two reasons. Get a clear signal that WebGPU is coming. Origin Trial is usually the last phase toward shipping an API in Chrome Stable. And to get real developers starting to use the API, so we can get feedback from larger / more concrete applications.
  • JG: larger / more concrete apps have no other blockers. They can do the development already. I worry that this becomes Christmas Day, I sign up for Origin Trial in Chromium, ship it in Chromium, good to go.
  • RC: Origin Trials expire.
  • JG: I understand that in theory.
  • CW: I don’t think this group is the right place to discuss Chrome Origin Trials.
  • JG: it is the place to debate health of the API. Based on my feelings I’d like you to take care. Don’t advertise this as a prerelease API.
  • CW: that’s what Wasm did. Prerelease API, try it, we’re going to break it. Please try it, then realized we needed to add COOP / COEP.
  • JG: I was worried by Dominic’s question & satisfaction with the response. Think most people will think that.
  • BJ: experience with WebXR: we had multiple origin trials. Saw some good positive feedback from folks like Matterport, Sketchfab. They could do promotions. There was a “works best in Chrome” thing attached. but we did use it as a progressive enhancement or alternate mode. One area we messed up - avoid this - we got into a mode where we thought we were on the cusp of shipping, but had to back off multiple times. We kept renewing the Origin Trial to not break people who’d built content with the expectation it was about to ship. A bad place to be. We were better about this with future communications. We found that worked really well - worked closely with the developers, had understanding that it was temporary & would break, and that the OT was not a guarantee it was going to ship - was the best way to get good feedback & less friction when the OT was turned off, which is part of the shipping process.
  • DC: I’m just excited it’ll be in a production browser in a few months.
  • JG: I’d encourage you to try it before it’s in the production browser. Once it’s there we can’t change it.
  • DC: I’ve been using it for months on Canary. To let other people look at stuff without downloading Canary will be terrific.

Agenda for next meeting

  • Some of the multi-queue discussion?
    • JG: yes please.
    • CW: I’ll do the list of things to consider before the homework deadline.
    • KR: possible for DM to help? he had some great earlier MQ investigations and CW’s taking a lot of the burden.
    • DM: sure. :) will sync up.
  • JG: list of things to discuss before V1?
    • CW: yes. Let’s build that list offline.
Clone this wiki locally