Swap chain creation failed

Started by
15 comments, last by galop1n 6 years, 7 months ago

Correct, BGRA isn't supported as a UAV. I'm pretty sure it's an oversight, but UAV access was only ever enabled for the RGBA channel ordering.

Advertisement
On 6-9-2017 at 8:23 PM, galop1n said:

As UAV for backbuffers is kind of deprecated anyway, i would recommend to not use that, create a separate resource and just perform a final copy to the swap chain at the end.

It is easy to fix, but since using the back buffer as a UAV seems so natural for GPGPU stuff, I wonder why forcing the detour in newer versions?

🧙

8 hours ago, matt77hias said:

It is easy to fix, but since using the back buffer as a UAV seems so natural for GPGPU stuff, I wonder why forcing the detour in newer versions?

This is the answer of a Microsoft guy on the topic

Quote
D3D12 doesn't support unordered access on swapchain buffers, because the bindless nature of UAV access conflicts with the ability to synchronize/validate writes to those buffers. D3D11 does not have this restriction.
 

 

6 minutes ago, galop1n said:

the bindless nature of UAV access

What do you mean with "bindless nature"?

🧙

In D3D12, you can create a descriptor table containing 1,000,000 UAVs, and use data passed to the shader in order to determine which ones are being used. That, combined with the fact that they're GPU-side descriptors (which don't need to be initialized until GPU timeline execution of the command list) means that we can't just inspect which resources are "bound" to the pipeline via UAVs like we can with render targets, which only use CPU-side descriptors and only have 8 slots. We require the ability to track back buffer references in order to synchronize with the display so that VSync presents work correctly.

So, as long as that VSync synchronization is implicit, it precludes UAV access to those resources.

17 minutes ago, matt77hias said:

What do you mean with "bindless nature"?

With DX11, it is easy, you want to write to an UAV, you have to bind it at a fixed slot with a single API, and it is represented with a fat iUnknow object.

 

With DX12, all you need is to allocate a slot in a descriptor heap, set the offset as a descriptor table and voilà. The thing is that the descriptor validity is up to the user, they are volatile, you could even set them after the command list is closed if you feel like it, or set some fence and trigger some nifty callback to late set a descriptor based on whatever. To be short, who knows what may be done !

 

This is why they can't assume anything and for the back buffer that has stronger requirements for being used by the compositor, it was not ok.

This topic is closed to new replies.

Advertisement