19 hours ago, ajmiles said:
-
Do you have the Debug Layer turned on?
-
What does your call to OMSetRenderTargetsAndUnorderedAccessViews look like?
And 3, I fail to see how this is going to produce desirable results. The execution order of reads/writes to the UAV is inherently 'Unordered' (it's in the name) and so trying to do any sort of "Read-Modify-Write" on a floating-point UAV Texture in the pixel shader every time the it gets invoked is going to be non-deterministic.
How does this reduce overdraw? It sounds like you're still binding a Render Target and writing something to it?
Could you go into a little more detail how it is you think this technique will a) Be deterministic and b) Perform better than what you were doing before?
1. Yes of course Debug Layer is on.. No Warnings or Errors.
2. I am using SlimDX so I don't call that method nativly, but it looks like this:
Dim UAVs() As UnorderedAccessView = {Overdraw.UAV}
Dim RTVs() As RenderTargetView = {Path.HDR_Buffer.RTV}
C.OutputMerger.SetTargets(View.DepthStencilView, 1, UAVs, RTVs)
About my idea:
I thought about to have a "coverage texture" parallel to the RenderTarget to check how much alpha was already drawn to the current fragment in order to discard any further draws if a specific value is reached.
In order to simply test if a UAV can be written and read in PS i just tried something like that:
RWTexture2D<uint> Overdraw; // only R32_UINT are supported..
float4 main(PixelShaderInput input, float4 coord : SV_POSITION) : SV_TARGET
{
...
uint2 uv = (uint2) coord.xy;
if (Overdraw[uv] > 0) discard;
...
Overdraw[uv] = 3;
...
}
But nothing gets discarded.
About "unordered".. yes you are right, but I thought also the execution order for all fragements in PS is also "unordered"
