Skip to content

Minutes 2021 06 14

Jump to bottom
Corentin Wallez edited this page Jun 18, 2021 · 1 revision

GPU Web 2021-06-14

Chair: Corentin Wallez

Scribe: Ken, Kai, Jeff, [others]

Location: Google Meet

Tentative agenda

  • CTS updates?
  • Implicit BGL conflicts with de-duplication #1806
  • Remove the read-only texture storage bindings #1794
    • Allow read-write storage on selected texture formats #1772
    • "Sampled" is ambiguous in the spec #1785
  • In a single shader instance, can one render target or resource alias the storage of another? #287
  • Investigation: Compressed Texture Formats #144 (decide what extensions are guaranteed to be supported in WebGPU)
  • Agenda for next meeting

Attendance

  • Apple
    • Myles C. Maxfield
  • Google
    • Brandon Jones
    • Corentin Wallez
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Francois Guthmann
  • Michael Shannon
  • Mehmet Oguz Derin
  • Rick Battagline
  • Timo de Kort

CTS Updates

  • KN: working on documentation for all the helpers - e.g. creating resources, checking their contents. Almost done. Link to the docs will be in the README in the CTS; easy to find.
  • KN: used to have an index that we intended to fill out - never did it - now using a documentation generator. Almost done, just need to land it. Reduces the amount of code you have to write to add a test.
  • CW: the CTS is already helping find driver bugs. e.g. nonzero mip layers of depth textures are busted on Metal / Intel. Expect workarounds to be needed in implementations.
    • MM: did you file these?
    • CW: Not yet.
    • MM: I'd like to see them.
    • KR: would it be okay to submit feedback reports with WebGPU CTS tests rather than native Metal test cases? Boiling them down takes quite a lot of time.
    • Discussion about whether it'd be OK to file these reports if they run in Chromium.
    • MM: WebKit team as distinct from Metal team would be happy to help reduce these.
    • CW: we'll send emails.
    • DM: we're concerned about bugs in Apple tech. If Corentin files the bug we have no visibility into it. Would be very much welcome if we could see what happens in these bugs.
    • MM: not unreasonable, has happened in the past. I'll get the ball rolling on that. If we pick a different policy for these bugs, have to decide which bugs go into that set, or not. Some formal description. Can follow up offline. Please include Dzmitry in the offline email thread.
  • KN: there are some good first bugs. Don't have a list right now, but if anyone will have time to work on the CTS, I'll send you potential things to work on.

Implicit BGL conflicts with de-duplication #1806

  • DM: one user of WebGPU tried to get a BGL from one thing, and use it on a different thing. Failed at draw time because BGL wasn't compatible.
  • DM: triggered a warning for me - if the implicit BGL adhere to the same pipeline compatibility rules we have - it's easy to accidentally use it, will sort of work, and then you make a small shader change and it fails at draw time. Or maybe not. A mistake hidden in your code.
  • DM: That'd be fine - we have draw tiem errors. But not very useful. If you want to use BG between pipelines - please declare your layout. That'll help people think about this. Doesn't require deduplication / compatibility for those implicit layouts.
    • A lot of discussion on this on the Matrix channel. ~10 different proposals on what to do with it.
  • CW: yes. A couple that people like better than others.
  • MM: even in current flawed state - still better than nothing. Think we shouldn't pursue a solution involving removing getPipelineLayout().
  • CW: strong +1. 2 solutions in that direction:
    • Make getBGL not consider static use. Grab all bindings used by ShaderModule. If you change your code, set of bindings stays the same.
    • Keep things as-is.
    • Want to tell developers, implicit layouts are for use only with this pipeline you got it from. Pipeline deduplication takes into account the pipeline. In addition to its descriptor, knows what pipeline it comes from, and the index it comes from. Used in deduplication.
      • Maybe, combination of things that created the pipeline.
  • MM: your VS can come from one module and FS from another. getBGL coming from a module - which one should an author call it on? Or maybe only valid if VS/FS come from same module?
    • CW: getBGL would still be on the pipeline. Would consider all the bindings of both ShaderModules. If conflict, pipeline creation fails. Many options though.
    • MM: has to be fallible, because these things can collide. Another option: if they came from different modules, fail.
    • MM: want authors to put as much source code into ShaderModules as possible, so in that scenario, option #1 doesn't seem bad.
  • CW: option #3 is pretty attractive, I think. ("option 5" on github)
    • DM: if the layouts are unique that'd solve it. Still opens a way to relax this later.
    • BJ: from my experience, I like using getBGL when available/makes sense. When I need to do sharing I have to fall back. I implicitly treat things as though option 3 is already in effect. Non-obvious to me what the rules are that build up that BGL. Implicitly treat them like they only work with that one pipeline. Seems to be the case most of the time. Not that harmful to people trying to use it.
    • MM: would like some way to differentiate which one's able to be used in which pipeline, so it's not magic for the developer - can ask which pipeline a BGL is compatible with.
    • DM: in this scheme the user knows which pipeline it's compatible with. It's the one they got it from. Why does API need to expose this?
    • MM: in case they have a cache, and when they put it in the cache...seems more convenient.
    • BJ: hard to think of many scenarios where you need this.
    • KR: suggest using expando properties to put the pipeline on the BGL.
    • BJ: concern: get implicit BGL, then use it as the explicit BGL of a new pipeline. Allowed?
    • KN: if we explicitly associated them I wouldn’t expect that to work.
    • CW: Also if you getBindGroupLayout from a PL created with explicit layout.
    • MM: if you have BGL can you get the descriptor it came from?
    • KN: opaque.
    • MM: that nullifies my previous comment then. If opaque, then if authors will cache them they have to create the keys themselves.
  • CW: bunch of interesting questions associated with this.
  • DM: let's proceed then. "New Option 3".

Remove the read-only texture storage bindings #1794

  • Allow read-write storage on selected texture formats #1772
  • "Sampled" is ambiguous in the spec #1785
  • DM: read-only storage binding is a thing that's not a concept in either D3D or Metal. Not a concept in Vk host API either. Just "storage" - generally writable. In shader, can say you won't write to it. Host API - just determines how you synchronize access to it.
  • DM: when we map to those backend APIs - readonly storage maps to textures on Metal, SRVs on D3D. Vulkan, mapped to storage texture. If we removed this path in the WebGPU API - this won't restrict what the user can do. Can still use same textures as sampled bindings. Can still load data from them via textureLoad, like they do today.
  • DM: for this reason, I think we should remove RO storage textures.
  • CW: what happens when we add RW storage textures? Do we add this back?
  • DM: it'll be a different type. Nothing to do with RO storage textures. RW storage textures - everything's different host-side.
  • CW: shader has accesses for storage texture. Is there a case with compute shaders where impl wants to know it's a storage texture, but want to take advantage of synchronization being unneeded between multiple stages where they all read from it?
  • JG: can you take advantage of static analysis of shaders? Know whether it might write to it.
  • CW: even better - have access declaration.
  • CW: maybe we can cross that bridge when we add RW storage textures. Today, RO storage textures don't make sense, and are confusing - they map to SRVs on D3D12 rather than UAVs.
  • JG: if we remove these bindings - what are we left with?
  • CW: sampled, or write-only storage textures today.
  • KN: you use texelFetch.
  • DM: texelLoad in WGSL.
  • MM: so not write-only.
  • KN: for write-only you can't do that.
  • JG: so we'd have RO type "sampled", and …
  • KN: it's what we call "sampled" usage today. Becomes shader-read.
  • JG: so we're removing separate binding type for if you want to sample from it, but wanted it to be read-only.
  • CW: I have concerns with shader read but that's a different discussion.
  • CW: so nobody wants to keep RO storage textures for now? Right now they're just sampled.
  • Discussion about replacing things with shader-read.
  • CW: would like to talk about that separately. Concerns that when we add RW storage textures we'll want RO storage textures, and then shader-read is confusing - can you bind it to RO binding point? No.
  • DM: can't sample integer textures on D3D12.
  • DM: we can follow D3D and call it a Shader Resource. Can do offline. Imp't: get consensus about removing the thing, to start with.
  • JG: if no difference in backends, they should become only one thing.
  • KN: D3D - no difference. Not sure about Metal. Vk - there are multiple ways to do it, and there are perf differences between RO storage and sampled.
  • JG: my instinct then is to expose the difference to the API.
  • KN: doesn't map well to D3D though.
  • JG: it's a question of whether it should be built in. Should we surface a detail that has perf implications on some but not all backends? Sometimes. Is this one of those sometimes? It's a perf difference in Vk that's there for a reason. Concern about Metal.
  • DM: there (is / isn't?) a perf difference for Metal.
  • MM: texture type in shader has enum, sampled, sampled/RW or RW.
    • enum class access { sample, read, write, read_write };
  • JG: concern if people had to optimize their read performance when we later add RW resources, and they start using that when they want to read.
  • DM: we can cross that bridge later. Can add RO storage textures later, but don't think we need that.
  • KN: RO storage available for many more formats than RW storage.
  • CW: WebGPU's sync rules say you can use RO with sampled. Not possible to map to same semantic on D3D12. Only UAVs there, considered RW. D3D device says it's a data race. Later, when we add RW storage textures, we can add RO ones, and say you can't use them with sampled. Can map well to things on all 3 APIs then. Sync rules today don't make sense, or prevent faithful conversion to backends.
  • CW: suggest we resolve by saying we remove RO storage textures today, for MVP. See whether we add it later for V1. Either an extension or core depending on availability on Metal. And/or consider adding back in RO storage textures later.
  • DM: sounds good.
  • JG: seems we're punting things down the road.
  • DM: just really not needed.
  • JG: not needed today, but we'll get there in the future.
  • DM: not clear. CW is hypothesizing - maybe cache access pattern in Vk on a particular layout will be 1 ns faster.
  • CW: I can point at people explaining that it takes different hardware paths.
  • JG: diff HW paths indicates to me we should preserve that. Agree API shape today doesn't make sense.
  • CW: happy with removing it, or changing synchronization scope rules.
  • DM: new shader RO will be compatible with write-only?
  • CW: yes. And can't be used with other RO usages, because of D3D12.
  • DM: a little dangerous. If writing shader code, wouldn't expect it to change between different loads.
  • CW: we have another item about this on the agenda.
  • MM: used to be 2 enum values. In order to use WebGPU correctly, will all textures have to be write-only?
  • KN: only storage textures. Intend to add read-write, possibly read-only in the near future.
  • CW: maybe we change the usage scope rules. Solves that concern. RO can't be used with other RO state. Related to next item on agenda.
  • DM: not just spec change. It'll delay the release for no strong reason.
  • JG: it's about, do we want to get to the point a year in the future, to accelerate our V1 release. I'd rather do the thing we know we need to do.
  • CW: in terms of tests - we're just going to change Dawn's implementation and fix the tests. We already have the tests.
  • DM: I don't know whether we'll need it. Why prioritize it now? Being cautious?
  • CW: avoiding churn in the API. Jeff's saying, don't remove something we'll re-add in 6 months.
  • DM: I don't know whether we're going to re-add this.
  • DM: This isn't about read-write at all.
  • JG: on Vk would hit different HW between RW and sampled. CW mentioned, ppl would have diff perf characteristics. To get better read perf, have to use RW textures.
  • CW: can see a time when you use RW textures when optimizing barriers in compute shaders. Don't want to put barrier in when texture's used as RO storage, and later as RO storage again. Having author tell you, this texture's access-read, gives you lot of information about barriers. I think we will want RO textures because it tells us more about what developers are doing with the textures.
  • DM: I'd need more info about that. Not sure how it'll help with barriers yet.
  • MM: with this change, only 2 ways of attaching texture to shader: write-only, or sampled.
  • DM: yes.
  • CW: help clarify whether RW storage textures are a thing. Take some offline time.
  • DM: i think the new RO storage texture needs to be separate investigation and discussion. Nothing like today's. You're saying sightly tweak it, but we haven't discussed it.
  • CW: let's discuss on the issue.
  • MM: in Metal backend - write texture would be access::write in Metal? … and then we'd add another RW enum. There'd be two, WO and RW? Think that works out great for Metal.
  • DM: in addition, with this proposal - impl can see no sampling going on.
  • MM: these barriers - get inferred from access parameter of texture.
  • CW: is that comment from Myles sufficient to explain why we need RO storage textures in the future?
  • DM: no, because …
  • JG: web app author will say, this is RW, then only read from it…
  • DM: If it’s described as sampled, and we see there is no sampling going on, we can use access::read instead of access::sampled.
  • JG: OK
  • CW: discuss about RO storage textures offline. Too many words about these things without a whiteboard. Let's do it in writing.
  • MM: can that strategy of looking at shader to see how textures are accessed - can those optimize the barriers Corentin's talking about?
  • JG: Sure
  • CW: depends when you want to generate your shader. If you generate at pipeline creation then you have a single entry point and everything is great
  • MM: it's not pipeline creation time. It's if you have the pipeline layout. App might give you pipeline layout at shadermodule creation time, and we would happily do compilation.
  • CW: if there's RW but no RO, you could look at shader, see texture's never written to, and demote it to RO. seems complicated to do in general case.
  • MM: impl difference. We only ever do compilation when we have pipeline layout, you try to do before, so optimization'll be harder for you.
  • DM: your impl's compiling only with a pipeline layout now, no?
  • CW: maybe - didn't follow, but think we should move on at this point.
  • CW: took AI to discuss what RO storage textures would be useful for, and whether we want them in the future.

In a single shader instance, can one render target or resource alias the storage of another? #287

  • CW: very old issue. Aliasing of writable / RW stuff.
  • CW: everyone agrees - we don't allow single texture to be bound to multiple render targets in the same renderpass.
  • DM: that's already in the spec.
  • CW :do we let a single buffer be bound as storage buffer multiple times? RO storage buffer to be bound as writable storage buffer at same time? (aliasing)
  • MM: binding same buffer twice as RO, no problem. But if RO/RW aliasing, trouble. In beginning, I think we should say no aliasing. If someone comes along wanting to bind things multiple times, RO and RW, I think that'd be a thumbs down.
  • KN: doesn't have to be same draw call - instead, render pass.
  • MM: right.
  • CW: concerns with that. Increased draw time validation. Also easy to imagine shader authors having RW buffer. Today, RO buffer in shader, can use it with pipeline layout saying RW buffer. RO promoted to RW. Means: in shader, if I write readonly, depending on layout there are diff rules. Different draw in renderpass decides to read/write - surprising things can happen. Think we should let people have data races - that's how you use GPUs in the most efficient way - controlled data races. Only for storage buffers though.
  • MS: with regards to disabling aliasing - we currently use this, to get around bug? optimization? that we don't want there in the Metal driver. We send texture twice so it'd be treated as separate samples. To get around optimization that breaks a certain algorithm.
  • MM: would like to hear more. Can you explain more over email?
  • MS: yes.
  • DM: concerned about CW's case that happens today. Don't think it happens by design. If you use RO storage buffer pipeline might use it as RW. Think it should match 1:1.
  • MM: certainly shouldn't be promoting things to more expressive than pipeline layout describes.
  • DM: in this case it's promoting to the pipeline layout. User who writes the code sees it's a RO buffer. Expectations are messed up.
  • JG: could we get an example for this? Having trouble following spoken examples.
  • CW: we can keep discussing on the issue.
  • KN: I'm not confident that users want RO storage buffers to never change underneath them. RW storage is limited to certain formats.
  • (we're talking about buffers)
  • KN: not sure why you'd have one thing writing into resource, and another reading from it in a different draw call.
  • MM: impl will optimize this - no point where these reads can get new data, so I'll hoist them out of a loop.
  • KN: not even in a loop. Do a read, and not be sure whether they got updated data or not. Still use it.
  • MM: outside of a loop?
  • KN: writing in one draw call, reading from another one.
  • MM: if you lose the race, you need a loop.
  • CW: difficult to discuss. Let's discuss in writing.
  • DM: the issue we have is confusing. Think we need a new issue. The subject talks about render targets, but we figured that out long ago.
  • MM: would like to see example of Kai's idea.
  • KN: I don't have a specific algorithm in mind.
  • DM: I'll follow up with an issue. In Kai's example, just use RW on both sides.
  • KN: agree, not on buffers.
  • CW: I'll comment on the issue.

Investigation: Compressed Texture Formats #144 (decide what extensions are guaranteed to be supported in WebGPU)

Agenda for next meeting

  • Compressed texture formats (early in the meeting, so we get to it)
  • Various types of aliasing
  • RO texture storage and potential removal
  • Anything about GpuAdapter.name?
  • Figure out whether indirectBuffer OOB is a validation error #1834
Clone this wiki locally