Skip to content

Minutes 2019 04 15

Corentin Wallez edited this page Jan 4, 2022 · 1 revision

GPU Web 2019-04-15

Chair: Corentin

Scribe: Ken

Location: Google Meet


  • ImageBitmap #266
    • Concern that the ImageBitmap needs to be remembered between encode and submission. Discussion around read-only and weak handles.
    • ImageBitmap has to be not detached.
    • People like the proposal (but no consensus recorded)
  • Discard store op #97
    • The clear optimization is pervasive in GPUs.
    • Naming discussion, discard, don’t care, discard to zero, mark zeroed.
    • Would still like to talk about it when DM is there.

Tentative agenda

  • ImageBitmap
  • getSubData/setStubData #213
  • Discard store op #97
  • Agenda for next meeting


  • Apple
    • Dean Jackson
    • Justin Fan
    • Myles C. Maxfield
  • Google
    • Austin Eng
    • Corentin Wallez
    • Dan Sinclair
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
    • Ryan Harrisson
  • Microsoft
    • Chas Boyd
    • Jungkee Song
    • Rafael Cintron
  • Mozilla
    • Jeff Gilbert
  • Joshua Groves

Administrative items

  • CW: Start having implementation roundtables?
  • CW: Publish a resource on how to try WebGPU in each browser?
  • CW: fbeaufort@ might want to put this up.
  • CW: please reply to announcement of F2F so we know you’re coming.

ImageBitmap #266

  • KR: One of the issues was that ImageBitmap doesn’t guarantee that the content is on the GPU. The Web spec mandates it be easily renderable but not necessraily on the GPU. So primitive cannot be “please wrap this ImageBitmap” in a WebGPU texture. Implies there must be at least one copy from the ImageBitmap in the WebGPU texture.
  • KR: Another pain point of WebGL is that folks want to take a sub-rectangle of an ImageBitmap and copy it in the texture.
  • KR: So the primitive can be “take a subreactangle of the ImageBitmap and put it in the destination texture”. Seems to be a good general small API that works for many usecases. Depending on ImageBitmap type could be a macro command that does the upload.
  • JG: at some point we’ll want some sort of dynamic texture thing, but this is good to get us off the ground. What’s the plan for sliced textures? Size is a 3D extent and not a 2D extent.
  • CW: this was just to mirror the CopyTextureToTexture entry point.
  • JG: so size.z is always 1?
  • KN: good question. Do we want to have slicing semantics?
  • JG: slicing semantics are pretty tricky. Maybe more fiddly. Some of us know how it’s done in OpenGL and it could be better exposed. If we could say that you copy slice by slice it’s probably for the best.
  • CW: was going to say it’s already the case for buffers and textures, but it’s not true. Copying slice by slice sounds fine.
  • KN: we could change the Origin so it doesn’t have a Z parameter.
  • JG: sounds good for MVP.
  • RC: one concern is that we resolve ImageBitmap at submission time. If we’re building native cmdbuf on the fly what happens? And what about building vs. submitting on different threads? Esp. for Canvas2D, where when you submit it you could get a completely different contents for the ImageBitmap.
  • KR: what does different contents mean? They’re read-only.
  • RC: ok, that doesn’t apply. But I think copy should happen when you make the command list and not when you submit it.
  • CW: you can wrap the ImageBitmap during encoding. If you can ever write to ImageBitmaps you can always do copy-on-write.
  • RC: so when you see CopyImageBitmapToTexture you won’t make a copy then and there? You’ll just write enough to make the copy later?
  • KR: we don’t know right now how encoding / submission on different threads will work. Could require transferring the ImageBitmap to the target thread, or have validation error.
  • Discussion about ImageBitmaps being read-only and why not pass a copy of a lightweight handle?
  • RC: if you can pass everything you need to a different thread, then I think everything’s OK.
  • KN: I think it really only has to not be detached. Has to be available on the thread where you submit it. If you make a shallow copy it should work. CopyFromImageBitmap, not sure if it makes a copy.
  • RC: we should make sure ImageBitmap is always read-only.
  • JG: thanks for providing the rendered version.
  • KN: did this by pointing to the .md version in my branch.
  • JG: if it’s immutable then we should be able to strike the line about when it’s referenced.
  • KN: it still has to not be detached at submit time.
  • JG: might be easier to say, explicitly say, if it’s detached at submit time it’s an error. Otherwise I like it.
  • DJ: we like the idea. One question: not saying, if you detach it, you don’t instigate a copy, you go into an error state?
  • KN: kind of the same as if you destroyed a texture before the submit.
  • DJ: OK. We like it.

getSubData/setSubData #213

  • CW: did you have a pull request to remove?
  • JG: didn’t get it done by the Friday deadline. Next week.
  • JG: there’s some color to the PR. I’m also clarifying what a user shim would look like. Think it provides value. Would like to defer it.

Discard store op #97

  • CW: there were 3 proposals. Naming wasn’t clear. First idea was to add discard, either clear-to-zero or store depending on arch. Most people against the idea. Other 2 ideas: when you discard, it makes the impl lazily clear the sub-resource tagged as discarded; or, do the same thing, but force user to do it in validation. If user forces discard on resource, they have to write to it, and we validate that.
  • MM: procedurally, thought we agreed on how this would work?
  • CW: we didn’t agree. We were stuck on validate vs. do it on the users’ behalf. This is why it’s not in the spec or IDL.
  • JG: I like the idea of enforcing that the users did the right thing, and do the clears properly. We don’t have to run-time branch on cmdbuf submission, whether we’re supposed to patch it into load/clear/etc. Better if validation forces the users to do the right thing.
  • JG: didn’t we strike proposal 1 earlier?
  • CW: given way API is going, we try to make it stateless. Bind group inheritance rules we decided not to do so we have less stateful updating. Better to do the lazy clear on the user’s behalf. At DevTools / etc., we can tell them if they forgot to do it. Would see it as a perf warning more than a validation error.
  • JG: load vs. clear: clear is never slower than load.
  • CW: maybe on very old GPUs but they don’t matter.
  • JG: the clear optimization is pervasive even outside of tilers. Store is not so obvious. Store ops are just store + discard?
  • CW: yes. And most of us should have a lazy clear infrastructure in place, even if only for resource initialization.
  • JG: if that’s the way we do resource init, we should probably just have load do an implicit clear if it was discarded.
  • CW: what about: discard the texture, and then if you copy to it (or from it), that should still count as a lazy clear?
  • JG: instead of discard - would like it to not be store-to-zero.
  • CW: naming is hard. “Discard” is great.
  • JG: can call it “discard”. Loading from uninit resource is the same as loading 0.
  • CW: load ops are load+clear, store ops are store+discard?
  • JG: yes. Comments from Rafael / Apple?
  • RC: Dzmitri proposed #3, can he give feedback?
  • JG: he’s on vacation.
  • RC: it went back and forth between him and Corentin a few times.
  • JG: we can make this decision here and then talk about tracking validation later.
  • MM: what will the final IDL look like?
  • CW: load ops are load+clear. Store ops are store+discard. Does that sound good?
  • RC: seems fine to me. Don’t feel strongly about this or proposal 3.
  • CW: this is one of the major glaring points in the API. Aside from this: Intel did multi-sample sample mask investigation. PTAL, can discuss next week.
  • MM: what does discard map to in Metal?
  • CW: there’s an equivalent for sure.
  • DJ: there’s UNKNOWN and DONT_CARE.
  • JG: it’s likely DONT_CARE.
  • CW: it’s DONT_CARE in Vulkan too.
  • MM: are we going to have semantics that you don’t know what’s in your buffer after discard?
  • CW: we don’t want that undefinedness. Lazy clear to 0. Semantics are clear-to-zero, but most impls will have lazy clearing for resource init. If you discard, you tag that sub-resource as something needing clearing.
  • MM: can we call it something more descriptive in the IDL than DISCARD? Think that proposal makes a lot of sense, just want to get the name right.
  • KN: think DISCARD is good. Discard what you wrote and now it’s zero.
  • DJ: what about CLEAR, and say it’s fast?
  • JG: don’t like that. Depends on how we handle uninit resources in general.
  • KN: correctness semantics are the same, but performance semantics are imp’t.
  • JG: what about DISCARD_TO_ZERO?
  • MM: sounds like OK compromise.
  • KN: could call it MARK_CLEARED or MARK_ZEROED, etc. Could have words for uninit resources.
  • MM: maybe can resolve for now and come up with a name later.
  • JG: sounds good. Does anyone want to volunteer?
  • (silence)
  • RC: so if you discard, and then bind as source, you’ll get zero?
  • KN: yes. And if it puts it into a state where you have to bind it yourself, have to match. (?)
  • DJ: at this point, if we have editorial text, would be great if we could put that into the PR. (into the
  • CW: would be good to do this for the ImageBitmap PR as well.

Defaults patch

  • MM: can we agree to merge this?
  • KN / JG: yes.
  • JG: special thanks to Dean for getting Bikeshed thing together and landed.
  • KN: most rebases are trivial because it considered everything a rename!

Agenda for next meeting

  • CW: SampleMask etc.
  • CW: should start building agenda for F2F.
  • CW: setSubData / getSubData
  • CW: should we start talking about queries?
  • JG: any more thoughts on conformance testing?
    • KN: I haven’t had time to keep working on it.
  • CW: we’re close to the point where Chrome on Mac can run WebGPU IDL, and will start running tests in Kai’s harness.
    • KN: and figure out how it’ll work with other stuff, like web-platform-tests.
  • CW: agenda is open for more topics.
  • CW: for compute shaders it’s useful for devs to know about size of shmem and number of warps. Have to think about fingerprinting. Let’s maybe talk about it at F2F.
  • DS: next Monday is Easter Monday.
  • DJ: have super-majority, let’s skip next week’s meeting.
Clone this wiki locally