Skip to content

Minutes 2021 10 25

Corentin Wallez edited this page Oct 26, 2021 · 1 revision

GPU Web 2021-10-25

Chair: Kai

Scribe: Ken

Location: Google Meet

Tentative agenda

  • Administrivia
    • (if people looked) Austin's samples in the gpuweb org?
    • Announcement: we have the "webgpu" github org. Will need to decide what to do with it.
    • Next meeting is an APAC meeting Wednesday at 5PM PST / Tuesday 8AM China Standard Time
  • CTS updates
  • Milestone triage (timebox 15m) #2073 (currently triaging V1 issues, start at #473)
  • Consider removing GPUCommandBuffer.executionTime #2156
  • Proposal: Add a usage bit to allow creating a view with different format when creating a texture #168
  • texture_2d_depth for loading depth values might be unnecessary? #2094
  • Removing the COPY* texture usages #2196
  • considered harmful #2191
  • Agenda for next meeting
    • Remember it is an APAC meeting.


  • Apple
    • Myles C. Maxfield
  • Google
    • Austin Eng
    • Ben Clayton
    • Brandon Jones
    • Gregg Tavares
    • Kai Ninomiya
    • Ken Russell
    • Loko Kung
    • Shannon Woods
    • Shrek Shao
  • Microsoft
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
  • Michael Shannon
  • Mehmet Oguz Derin


  • Announcement: we have the "webgpu" github org. Will need to decide what to do with it.
  • (if people looked) Austin's samples in the gpuweb org?
  • BJ: There was a concern about moving one person's samples.
  • We how have the gpuweb organization on Github! Donated by Microsoft and University of Illinois.
  • Continue developing under gpuweb org? Move it to webgpu org? Keep webgpu org for more community-driven work including Austin's samples?
  • MM: if we have a better name and a migration path we should use the better name. Also noticed people using the UIUC webgpu logo as if it were ours.
  • KR: Want to advocate moving these samples to the most official location. Carefully curated/refined and multiple contributors. These are canonical examples and [they’re relied upon by a lot of developers].
  • MM: my point was that there should be criteria about what shows up in this repo. Think you made strong points. If everything you said is correct think they're a good fit. Policy shouldn't be that we accept these samples and no other samples. Policy should be that we have samples that have such goals, points, showing things in as little code as possible - desires / goals for this. People should be able to add to them, remove them if no longer applicable. We should say "create a set of samples and populate it with a set of samples we already have".
  • KR: Absolutely the intent to have an open forum. Moving the repo would provide redirects so existing links go to the right place. Can put together contribution guidelines before or after moving the repo.
  • AE: I don't think we need to actually move anything wholesale. Agree we should define what we want samples to be, what goals are. If I were to do it again, what I made ranged from "here's a triangle” to “deferred rendering". Should define how we want things, what we want them to be. Not that many, can port them over / adapt them and add redirects as needed.
  • MM: lots of people write WebGPU code that we could import manually. How do we know which ones to import and not?
  • KN: wouldn't worry too much about the range of sizes. So few right now that we probably don't need to organize them. Better to make them available.
  • MOD (chat): (also there was a thought about how the samples use the utils provided inside the repo and whether that's consistent across all samples, and to what extend it stands copy-pasteable for a less-clued reader)
  • BJ: as owner of samples repo...having so many examples that you have to pick and choose is a good problem to have, and one not likely to emerge. Can have criteria, but think it's reasonable to look over existing samples - if any fall outside our bounds / desires, we can suppress/remove them from repo prior to transfer - but otherwise start with what's there, and build out from there.
  • MM: understand, would like to have criteria.
  • GT: like the idea of samples - why not just a link? Might have to argue about who gets links, don't need a committee for review - someone else's problem. Fact that the link's in the spec site means that people will find them. No less accessible. Don't need a committee code reviewing. Don't need these issues on our plate.
  • MM: I'd still argue about who gets links.
  • KR: easier to maintain and update after spec changes if in one place.
  • BJ: these are high quality examples which exist now. Think it's desirable to have them in one place - adds legitimacy.
  • MM: think that's good start.
  • KR: can we agree that we'll make the repo, copy/move some samples into it, and work on this in a more distributed fashion?
  • KN / BJ: do we want to use gpuweb, or start using webgpu?
  • BJ: one opinion to use the name of the API - webgpu. Anyone opposed?
  • KN: the "admin" repo could stay where it is. Move spec repo into webgpu org.
  • MM: mechanically we should move them all together. Too easy to mess things up if we leave some things behind in gpuweb.
  • BJ: think we should use some of the repos that we no longer use to understand how repo transfers work.
  • KN: SGTM. Think repos will move seamlessly. Projects - not sure. Interesting to figure this out.
  • MM: who's responsible for the transfer?
  • MOD: can help with migration of tokens for CI, etc.
  • KN: if we're all happy moving everything to webgpu org, when we create samples repo, we can create it under webgpu org.

CTS updates

  • KN: no updates from me this week.
  • BC: a couple of new intrinsic builtin tests have landed. My team's fleshing these out at the moment. Some tests going in regarding overridable constants, was completely broken. Bunch of CTS tests for entry point I/O landed, last week as well.

Milestone triage (timebox 15m) #2073 (currently triaging V1 issues)

  • V1 issues starting at #473.
  • #473 requestAdapter and adapter properties
    • Think we can just close this.
  • #425 uniform buffer block size issue on Metal
    • Consensus on this 7 days ago.
    • MM: don't remember discussing this 7 days ago.
    • KN: maybe was conclusion from a while ago only written up last week.
    • MS: thought this was brought up last week.
  • #405 can visibility be "none"?
    • KN: "none" is gone. 0 can be passed in.
  • #513 storage texture investigation
    • MM: if feature will be in v1, it'll be in v1 - but if postponed, we'd mark not-v1 rather than closed.
    • KN: we already have this feature though.
    • MM: if done then we don't need it
    • KN: it's a big feature, i don't know whether anything's missing
    • MM: let's @ Jiawei, ask for updates, close in a week if none
    • KN: skimming though I think there's nothing core to storage textures, just the formats we have. Sort of open investigation. Makes sense to leave it open for now.

Consider removing GPUCommandBuffer.executionTime #2156

  • KN: we're in favor of removing it because it's not universally implementable. Adds impl work not strictly necessary for relatively small feature. Can be imp'd on top of queries on most platforms.
  • MM: last week Corentin made point - large # of devices out there that have no ways to measure GPU times at all. If true, that's a showstopper. But some concerns that that might not be accurate.
  • KN: think I gathered info on what devices that ended up being - at least on ARM. Not sure where that data is now. My report - timestamp valid bits in Vulkan. Loses Mali devices from supported stack.
      “timestampValidBits != 0”
    • Don't know what those devices are nor how old they are. Reasonably large list though.
    • MM: presumably these are popular enough that we should aim for them to run WebGPU?
    • KN: not conclusive - Android Vk reports, not sure if it's old drivers for the device don't support it, or the HW doesn't support it at all. Most of these look like they have at least some support on some Android versions. Dig deeper to figure out which devices we'd lose? Safe to say this would impact compatibility at least somewhat.
    • MM: is path forward - someone buys one of these devices, see what the latest drivers report?
    • KN: think we can find it from database. See what reports have / don't have support. There are quite a few devices. In total of the reports, maybe half of this bucket of Mali devices doesn't support this? Want to support ~2 yr old devices.
    • MM: because you'll put new Chrome on old devices with old drivers for testing?
    • KN: yes.
    • KN: given # of devices - we'd probably have to somehow polyfill this. Providing fake data, either 0s or do some CPU timing and provide that. Doesn't map to execution time.
    • MM: think that'd be a mistake for this feature. App can measure CPU time. If it can't measure GPU time it shouldn't exist.
    • KN: in backend - not literally measuring CPU time, but approximation of how long it took on the GPU. Fence before/after work. Very approximate, might produce wrong results. Probably can't have this in core, practically.
    • KN: if out of core, are remaining timestamp query extensions sufficient?
    • MM: we could either delete this, or move it to optional as an extension. Don't think it makes sense to have 2 diff GPU time optional extensions. The devices supporting one but not the other. The less powerful optional feature would become less useful over time. Think it's not worth it.
    • KN: makes sense to me. Opposition to removing this?
    • MM: when developers ask how long their work took - there are some devices that don't know?
    • KN: they can estimate it with onWorkCompleted. Not perfect results. Can use framerates. Limited, but they can get something.
    • DM: can they still use platform-specific tools to get those timings?
    • KN: ideally yes. Easier said than done. If the platform has a tool and supported well by the tool, should be possible. Xcode can do this. Tool's timing info will be more useful anyway.
  • KN: think we can call that consensus.

Proposal: Add a usage bit to allow creating a view with different format when creating a texture #168

  • MS: continuation of last week
  • BJ: primary thing - should this be deferred to post-V1? Don't think anyone wants to remove it.
  • KN: sRGB reinterpretation - possibly the most likely case. You can do this with a copy if we allow copies to do it. More straightforward. Don't think I had any major use cases requiring doing this. All colorspace stuff - resolved without having to do texture view format reinterpretation. Probably don't need this in V1.
  • MM: think Jiawei has opinions. Give him some time to respond.
  • KN: yes.
  • DM: nice if we landed a mechanism for this, but not enable full range of format conversions we might want. Maybe, only allow sRGB reinterpretation at start.
  • MM: the mechanism is the question. A bit, or a list of formats. Talking with Metal team.
  • KN: bit vs. list is more complicated.
  • KN: tentatively, say if we don't find a very important use case right now, we'll add it later. Hooking into V1 probably not a problem. Can implement a little later. sRGB/RGB potentially important. Question of how we expose this bit - complicated.
  • MM: reasonable to make tentative resolutions. For now, think this is the right path forward.
  • DM: seems fine to me. Think providing list of formats is most compatible and future-looking decision.
  • MM: Metal team's brought up arguments not yet stated. Not ready to state them yet. Don't think any solution's obviously better than the other.
  • KN: that's what makes this tricky.
  • DM: of the 3 platforms we're targeting - even if Metal situation's not obvious, Vulkan solution is. IHVs need to know some formats require less code path changes than others. On Vulkan, it's optimal, and on Metal not worse than any other solution. D3D, we know we'll use typeless vs. typed. That's why I'm convinced this is the best solution.
  • MM: if we're discussing this based on its merits, I'd like another week to talk with Metal team.
  • KN: would like to try to conclude discussion, so let's wait a week for that input. OK punting to post-V1 if we can't get it.

(if Myles has list of builtins) texture_2d_depth for loading depth values might be unnecessary? #2094

  • MM: MSL has a depth_texture type distinct from texture 2d. Other SLs don't have a depth texture type. Just use texture2D in the other APIs.
  • MM: Q here: should WGSL have a depth_texture type or not? If not, in Metal you'd bind depth texture to texture 2d - against the rules, but happens to work.
  • DM: the q is whether we need this type. Not the question. We need this type regardless. We want to do depth comparison sampling.
  • MM: right. Q is: legal to bind depth texture to non-depth-texture type in the shading language? MSL spec says illegal, but in practice works most of the time.
  • MM: one hiccup: need depth-texture type in WGSL because there are some things it can do specially. Regular textures can also do things depth texture can't. 2 places in the docs where that occurs: gather operation, and texture write.
  • MM: Q then: if you write Metal program, bind depth texture to non-depth-texture type, and then call one of these non-depth functions?
  • MM: technically spec says it's illegal.
  • DM: write we can discard right away, that requires writable storage bindings. Gather - falls under same bin of behaviors as taking the YZW components you sampled from depth texture.
  • MM: problem here - we have no confidence that'll happen. If you do this operation you'd hope it'll happen, but not enforced because it's illegal.
  • GT: can you talk with Metal team and add to spec? First one, reading from depth texture, think if you removed the feature you'd probably break every Metal app. Pretty common feature.
  • MM: that makes sense. Interesting distinction: yes, common to sample from depth texture bound to texture 2d. Lots of apps do this, de facto something that works. Lots of apps don't run the gather function on a depth texture bound as texture2D. That we don't know works.
  • MM: if we allowed binding depth texture to texture2D in WebGPU, unclear what should happen if someone calls gather with Y component.
  • GT: what about if you're calling gather against this situation?
  • MM: possibly more draw-call time validation? There are some analyses we do like matching samplers to textures - some that we can't do - subtle. Need to think more.
  • MM: definitely don't want to have every texture have a bit, "I was bound as a depth texture or not", and have an if-test around every gather operation. No-go.
  • MM: easier if we could enforce that depth textures are bound to depth texture types.
  • DM: also not difficult if we allow shaders to pretend they're not depth textures, as long as the binding model knows they're depth textures. Can do all the plumbing, including the gather.
  • MM: might be the right path forward. Shader allows it, but binding model doesn't. If you wanted to bind depth texture to texture2D, in shader would be texture2D, but in BGL it'd be a depth texture. Would keep the shader people happy - could compile SPIR-V to WGSL faithfully.
  • KN: would we do analysis at pipeline creation time? If you use gather on this, you can't bind depth to it?
  • DM: not an analysis. It's the codegen at pipeline creation. You have the pipeline layout, know what to generate for gather op.
  • MM: so type outputted is a function of both WGSL program, and BGL?
  • KN: yes. Forgot pipeline's specialized to specific thing.

Removing the COPY* texture usages #2196 considered harmful #2191

Agenda for next meeting (NOTE: APAC timing!)

  • KN: Items we didn't get to from this week
  • KN: please add your items to the notes doc here for next week.
  • Agenda
    • (if we have new info) Proposal: Add a usage bit to allow creating a view with different format when creating a texture #168 (comment)
    • (continue discussion?) texture_2d_depth for loading depth values might be unnecessary? #2094
    • Removing the COPY* texture usages #2196
    • considered harmful #2191
Clone this wiki locally