Repository navigation
Consider associating the texture with its clear color value #284
Description
We could consider having the clear color to be a part of the TextureDescriptor. Justification:
- D3D12 specifically has this specified at resource creation and I vaguely recall this matching some of the specifics of AMD hardware (but need to investigate more to confirm this).
- it's not a common thing to vary the clear color for a particular texture.
- straightforward clear operation (in
RenderPassDescriptor) just being an enum of "clear"/"load" (related to Consolidate *loadOp and clear* into a unioned field #283 and Optional clear values #276). - we could still provide an API for clearing with custom values, perhaps as a simple
clearImagethat is performed out of the pass, orclearAttachmentwithin a pass.
Activity
kdashg commentedon May 8, 2019
This could be cool. Would we make RenderPassDesc.clearColor nullable, or just ask users to try to match the TextureDesc.clearColor and RenderPassDesc.clearColor?
kvark commentedon May 8, 2019
I think we wouldn't have
RenderPassDesc.clearColorat all. If the user decides they need to clear a render target with a different color, we can either:CommandEncoder.clearImage()that has a color parameterRenderPassEncoder.clearAttachment()that has a color parametermagcius commentedon May 8, 2019
The reason for the "clear color" on the texture is for fast clear semantics. The idea is that framebuffer compression likely has a few colors it can associate with "cleared target", and a clear will mark it as that value. Not all framebuffer compression can have more than one "fast clear" color (NVIDIA can support multiple, AMD can only support one, not sure about other GPUs), and some do not allow making fast clear customizable, hardcoding to either transparent or opaque black. They rely on users either marking loads as DONT_CARE, or setting their clear color to the one they support.
I can't remember if there's a way to get the "preferred clear color" for a render target in Vulkan. If there was, I would suggest exposing that, though it might be unpredictable across platforms.
kainino0x commentedon Jul 22, 2019
For the record, though we just merged #283, this may end up overriding that change.
kainino0x commentedon Jul 22, 2019
@kvark maybe we could put this on the agenda for next meeting? Since the topic is relatively fresh in our minds.
kvark commentedon Jul 23, 2019
@kainino0x sure, let's talk about this a bit next time. The change was initially motivated as a solution to clear value specification that we were discussing. Now there is less of an appeal, but it could still be useful, as long as we explicitly design it for fast clears.
kainino0x commentedon Jul 24, 2019
Yeah, it makes a lot of sense to me especially since D3D12 already exposes pOptimizedClearValue, and if we ever want to add clear color to RenderPassDescriptor, it would be a nonbreaking change. (Of course, having it there and adding it here later would also be nonbreaking.)
kainino0x commentedon Feb 14, 2020
(F2F) Direct from the D3D12 team: "Don't do this." Closed!
Add validation tests of CopyTextureToTexture - Part I (gpuweb#284)