Skip to content

Minutes 2018 10 22

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

GPU Web 2018-10-22

Chair: Corentin

Scribe: The amazing Ken!

Location: Google Meet

TL;DR

  • Next F2F will be in 2019 January 22nd afternoon and 23rd at Google San Diego
  • #92 Provide the attachments state when starting a render pass
    • The PR suggest having an AttachmentState object shared between render pipelines and render passes, would be a VkRenderPass in the implementation.
    • Validation could compare attachment states by pointer or value.
    • Concern it asks for redundant information at beginRenderPass.
    • Reach out to VK WG to make renderpass compatibility more flexible?
    • No resolution.
  • #97 Discard and don’t care
    • Proposal 1 vs 3. Do we lazy-clear or do we validate?
    • Ties in with resources being uninitialized when they are created.
    • Discussion on whether lazy-clearing is more expensive (CPU or GPU wise) than validating. CW to write more about it.

Tentative agenda

  • #92
  • Push constants
  • Discard and don’t care
  • Multi-queue
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
    • Myles C. Maxfield
  • Google
    • Austin Eng
    • Corentin Wallez
    • Dan Sinclair
    • James Darpinian
    • Kai Ninomiya
    • Ken Russell
  • Microsoft
    • Chas Boyd
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Joshua Groves
  • Timo de Kort

Admin

  • CW: Google can host a F2F in San Diego, Jan 2019. Need to pick dates.
  • WebGL is 21st and 22nd.
  • Try not to overlap with Vulkan Portability. Currently that overlaps with WebGL.
  • CW: I propose to have a WebGPU F2F both Tuesday afternoon and all-day Wednesday.
  • CW: We need more than 1 day, and we can finish discussion early to work on pull requests.
  • KBR: What is the transit time from Khronos to Google’s San Diego office?
  • (unknown)
  • CW: Let’s fix the dates - Afternoon of Tue 22nd January, and Wed 23rd January - at Google San Diego office.
  • FYI - The W3C plenary meeting is happening this week, and Myles and Corentin will be having a session introducing WebGPU on Wednesday

#92 - Provide the attachments state when starting a render pass

  • DM: want attachment state to represent concept of Vk renderpass, so that when we create render pipelines, we spec attachment state they’ll be used with; the attachment state is a handle to an object we bake; and when we start render pass, we spec the attachment state so that all the render pipelines used inside this render pass have to be created with the very same attachment state.
    • In impl, lets us create Vk renderpass for attachment state, and then when starting renderpass, can create different Vk renderpass with different clear values, but guaranteed to be compatible with original renderpass. Can use all original render pipelines and know they’re compatible.
  • CW: how does this help us vs. having the attachment format, sample count, etc. be in the render pipeline descriptor? Then create dummy render pass in Vulkan, etc… (didnt’ get all this)
  • DM: you’d have to match the pass on the backend level. Can potentially choose right render pass. This is the other choice. Do we want attachment state as a separate object or not? If yes, we should make it work like a Vulkan renderpass. If not, we can do what you suggest.
  • MM: what if we don’t do this?
  • DM: more work on the backend to match the formats all the time.
  • RC: right now the encoder has something you set on the pipeline. (??)
  • DM: renderpass is the scope of binding pipelines.
  • CW: FTR, the approach we have currently in Dawn is to have something like the attachment state. The attachment state also helps when we have multisampling. If we don’t want to recompile pipelines on Vulkan we’ll have to know which attachments resolve at the end of the renderpass, when we compile the pipeline. Attachment state will help ensure application provides this data.
  • DM: good point. When you create renderpipeline you don’t say that certain attachments will be resolved. That’s in attachment state.
  • CW: yes. I think it’s sort of a wart. Vulkan is missing some flexibility in the spec. If we have to do it, it’s best to have it in an attachment state rather than the pipeline object.
  • DM: also see certain value in the clarity of the API. You move errors earlier; mismatches are detected when creating render pipeline.
  • RC: you make renderpass, and in descriptor, you set attachment state. It’s already on the RenderPipelineDescriptor, and you set that via SetPipeline?
  • DM: yes and you set different pipelines through the pass. All the render pipeline states you set in the pass have to be created from the same attachment state.
  • DM: attachment state is an object, something you create beforehand.
  • MM: first render target is RGBA8. Second render target is 16-bit float. Shaders need modification. That’s why it’s in state object.
  • CW: also easier to specify validation rules between pipeline and render pass. Attachment states have to be equal by value.
  • RC: different attachment state in renderpass descriptor vs. pipeline descriptor -> error?
  • CW: yes. For example, RGBA8 != RGBA32_F.
  • RC: if we have to validate then why do we have it in 2 places? Should we eliminate one?
  • CW: that would involve compiling pipelines at runtime.
  • MM: when compiling the shader you have to know what the formats of the textures are which you’ll write into.
  • CW: that’s a constraint in all of the APIs.
  • DM: why “by value” semantics? Why not the same object?
  • MM: think that if an app creates a particular set of render targets w/formats, then any other way to create the same formats should match. Should look into contents of objects, not object equality.
  • CW: requiring pointer equality: 1) more difficult to have middleware that creates things, without creating “attachment state cache”.
    • JG: moving that to backend.
    • CW: true but it’s our responsibility to handle it.
    • Not sure what (2) was.
  • RC: in sum: we want this in renderpass descriptor because we don’t want to look where it’s too hard to look up?
  • CW: (2) was: if you do pointer comparisons, you have to do more work on the client side. Maybe the pointers are de-duplicated on the backend. Could make it so they aren’t, but it’s arbitrary details.
  • CW: when you start renderpass you have an attachment and know your states. When you have a pipeline, you want to know the attachment format / samples, and that’s in the attachment state.
  • RC: because these things are created at different times? That’s why you have to have state duplication?
  • CW: yes.
  • MM: when you create renderpass, you know the textures, etc. you’re rendering into. Should be obvious which pipeline states are valid. Why does render pass descriptor need to know the attachment state? That info should come from whatever textures you’re rendering into via renderpass.
  • JG: don’t think it contains everything.
  • CW: doesn’t contain resolve information. But we don’t have multisampling yet.
  • DM: could have a pipeline which renders into attachments 0 and 1, skips attachment 2, and want it to be compatible with other renderpasses.
  • CW: doesn’t address MM’s argument. Adding this adds a lot of redundant information. Already have format, sample count, etc. from the textures.
  • DM: these come later, inside the pass. Need to know this ahead of time. Either deduce this from format of textures that we have to pass in at the beginning, ...
  • CW: inside BeginRenderPass you pass in a bunch of textures for rendering. Can fetch their formats and sample counts there.
  • MM: that’s exactly what I meant.
  • DM: that’s one way to approach it. Not have attachment state as object. Can have a hashmap inside where you hash RenderPasses. (1) validation is simpler if you have an attachment state object and say it has to be the same. I say compare objects, CW says compare descriptors that created the object. (2) resolve multisample; you do not spec this when creating renderpipeline, but when creating one, needs to know that some of the attachments will be resolved or not.
  • MM: in this model you provide it as data. Not sure I agree that validation is more complicated, b/c you’re just running over a bunch of textures. Doesn’t seem difficult.
  • JG: part of this is ahead-of-time or while encoding. If require picking up formats from pipeline, you have to defer creation until later.
  • MM: is it common pattern in Vulkan to create renderpasses before you know which textures you’ll be rendering into?
  • CW: yes. You create renderpasses when you create pipeline.
  • JG: to create pipeline you have to create at least dummy renderpasses.
  • MM: yes, compatibility. Key thing is compatible. Don’t have to pass in particular textures.
  • JG: attachment state is not specific textures, rather the framework of formats of all those textures.
  • DM: at least we have to pass this info upon beginning of renderpass and creation of pipelines. In our backend
  • KR: If implementing Vulkan portability on top of this, will you have to deduplicate some Vulkan state into AttachmentsState because we compare by pointer? Will it induce bugs on client code if they don’t reuse the exact render pass?
  • DM: I want a Vulkan renderpass to have 1:1 correspondence to AttachmentState.
  • JG: agree with this.
  • CW: think Renderpasses in Vulkan are too inflexible. The fact that you have to create an object for single-subpass renderpasses, and the compatibility rules for them, are too strict.
  • JG: we can complain, but have to fold, because we have to follow the restrictions.
  • MM: we’re making a web API. Also, any complexity handled by the web application and not handled by our runtime: there will be many more authors writing stuff. Moving complexity into the browser is better.
  • JG: one of the issues here is that it encourages pipeline recompilation, which is bad.
  • CW: only in the multisample case, correct?
  • JG: yes, and that’s a case we’ll have to support.
  • CW: won’t be fixed in Vulkan 1.0, but would like to reach out to Vulkan WG about single-pass renderpasses.
  • JG: please do reach out but don’t want to make decisions based on future changes.
  • CW: not saying they didn’t weigh in on this. If you have multiple subpasses then the restriction makes sense, but single pass, doesn’t. At this point either having Attachment state or not.
  • RC: if we need to validate: do color attachments passed in match attachment state? And later, do the attachments match any pipelines you created prior to render pass?
  • JG: correct
  • JG: postpone discussion about pointer vs. value comparison. Also, CW, please talk with Vulkan WG about getting these restrictions relaxed.
  • CW: sounds good.

Push constants (#75)

  • CW: last time: ended up talking a lot about the cost of emulating push constants in the implementation with some sort of uniform ring buffer.
    • Engineers from Roblox gave a bunch of data.
    • Given the data, seems that we want to pursue push constants, but that was our idea in the first place.
    • Did this change anyone’s mind?
  • MM: haven’t had a chance to read this. Would prefer moving later today, or discuss next week.
  • CW: no worries.

Discard and don’t care (#97)

  • CW: 3 proposals. Want to do either (1) or (3). Do we want to validate that application clears uninitialized data, or do we want to do it on behalf of the application?
    • B/C we’re a web API seems we should do it on their behalf.
  • JG: generally I think we should not do that. Doing things silently on behalf of the user is generally a cause of falling off fast paths, esp. in graphics APIs.
  • RC: so you endorse (3)?
  • JG: yes. Seems good opportunity to make the user do the right thing.
  • CW: what about buffers?
  • JG: library.
  • CW: not as simple for buffers. Often app has buffer of a certain size, will upload parts of data but not all at once. Have to track valid ranges. If app makes off-by-one (which is easy) would fail validation.
  • MM: thought we were talking about texture load/store ops for render targets.
  • CW: b/c we have discard which taints the data, it joins with fact that creating textures/buffers makes garbage data. So the solution we choose for textures sort of applies for buffers too.
  • JG: Think it is a good approach then make the user do the right thing everywhere
  • RC: Since we are exposing don’t care, then a developer can upload only a portion of it. Too onerous to track all sub-rectangles.
  • CW: essentially, yes. For textures, can say if you have an invalid level, either you have to write all of it or none of it. But it’s more complex for buffers.
  • MM: how do you know that you’ve filled a texture?
  • CW: if you clear, we know you’ve cleared the whole thing. Copy from buffer to texture: would have to cover whole texture. (Seems arbitrary to do this for tainted textures.) Or track sub-rectangles, which is hard.
  • DM: i see how this is non-obvious for user. Case #1: (arguing against my own proposal) user creates buffer, runs compute shader against it. Since it’s bound as UAV, don’t know where they’re going to write to. Similar argument for textures. Shouldn’t require user to clear every level before they’re rendering into?
  • JG: mark fragments as cleared during load.
  • CW: still have to do LoadOpClear.
  • JG: it’s free.
  • CW: yes it’s free but saying that texture is tainted is kind of weird.
  • JG: what do we do else from this? Aggressively zero everything? Couldn’t lazily clear things.
  • CW: suggesting we lazy clear things if we need to. Every resource created with a bunch of zeros. Implementations work as though this was done.
  • JG: renderpass recompilation? If you’re choosing CLEAR vs. DONT_CARE, then DONT_CARE becomes a clear?
  • MM: one thing missing from discussion: performance numbers. Nice to know how much worse lazy clearing would be, rather than letting web author get into bad situation.
  • JG: can evaluate this. Need to think how API should work, rather than writing benchmark and saying it’s applicable everywhere.
  • CW: on CPU side, doing validation vs. lazy clear is the same cost as the application doing lazy clear if they’re doing everything correctly.
  • DM: user reading from texture that they should have cleared will create a performance hit that they didn’t expect. In Metal you’d have to insert a dummy pass right away to clear the resource. Don’t want to create the performance issue.
  • CW: user would do the same thing themselves.
  • JG: we should find compelling examples that differentiate these proposals.
  • DM: user could see error and change store operation in the last pass they rendered from. Cheaper than inserting dummy render passes.
  • CW: two concerns: (1) API is more brittle; validation is more stateful. (2) what about buffers?
  • DM: don’t see how validation differs
  • JG: error case vs. we fix it for you. In production, if it’s an error it’ll stop working. If we fix it for you it’ll be slower in some cases.
  • JD: think it’d be nicer to make it less brittle. Could issue warning if we do this automatically for the user.
  • MM: I agree with CW that if most apps won’t see a perf benefit then it seems unfortunate to be strict.
  • RC: clearing things when web developer didn’t expect it, because of errors on their part, isn’t a performance concern for you?
  • CW: that’s right. For example, in WebGL, if you upload texture data to mip levels then you don’t hit the uninitialized warning and performance issue. Worst case, you have a shipping application that’s slightly slower but doesn’t break due to statefulness of the validation.
  • JD: we’ll have a log where we can warn about these?
  • JG: yes, console.log. Can do better, but have always had this. It’s what WebGL does.
  • RC: WebGL was same / different. In WebGL if you didn’t TexImage2D everything, etc. then you wouldn’t get a validation error, you’d get black, and then have to look at perf logs.
  • CW: you’re talking about texture completeness. In WebGPU every texture is complete by definition. Also in WebGL, textures start cleared, but every browser does a lazy clear b/c it’d be too inefficient otherwise.
  • RC: understand. You’re saying all browsers do lazy clear but at the same time it has too high a perf cost?
  • CW: trading off errors.
  • RC: how complex is it when we have to figure out to lazy clear? Is that the same code we write when giving developer an error instead?
  • CW: yes. In successful case it’s the same CPU cost. In error case there’s more of a cost, but same GPU cost as if app had cleared themselves.
  • CW: I’ll take an AI to detail this in the issue for next week.
  • DM: we have several cases where user can trigger an error, similar to this one. Binding something as UAV and SRV, for example. Not trying to hide these. Why is this one different?
  • CW: because we can fix this one, where the other’s too difficult.
  • MM: agree.
  • CW: will take homework to detail this more on the issue.

Homework

  • CW: right now quite unstructured, wasting some time during meetings. Some more process could help improve things. For example, documents to read before the meeting. No more posting documents 1 hour before the meeting. Require posting them Thursday evening before the meeting the following Monday?
  • JG: what about 24h before the meeting? Like, Friday 12pm Pacific the week before?
  • CW: seems OK.
  • (More discussion. Everyone should have 1 full day to catch up on things before the meeting)
  • MM: so agenda is going to be published at the due date?
  • CW: thinking we can have tentative agenda at end of meeting the week before. Anything that hasn’t been posted by the due date is dropped by the agenda.
  • Agreement from CW, JG, DM on this.

Agenda for next meeting

  • Multi-queue #95
  • Decision on #92. Blocking DM’s implementation.
  • #75 Push constants
  • Submission model #100
Clone this wiki locally