• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By Krypt0n
      Finally the ray tracing geekyness starts:
      lets collect some interesting articles, I start with:
    • By lubbe75
      What is the best practice when you want to draw a surface (for instance a triangle strip) with a uniform color?
      At the moment I send vertices to the shader, where each vertice has both position and color information. Since all vertices for that triangle strip have the same color I thought I could reduce memory use by sending the color separate somehow. A vertex could then be represented by three floats instead of seven (xyz instead of xys + rgba).
      Does it make sense? What's the best practice?
    • By ZachBethel
      Hey all,
      I'm trying to understand implicit state promotion for directx 12 as well as its intended use case. https://msdn.microsoft.com/en-us/library/windows/desktop/dn899226(v=vs.85).aspx#implicit_state_transitions
      I'm attempting to utilize copy queues and finding that there's a lot of book-keeping I need to do to first "pre-transition" from my Graphics / Compute Read-Only state (P-SRV | NP-SRV) to Common, Common to Copy Dest, perform the copy on the copy command list, transition back to common, and then find another graphics command list to do the final Common -> (P-SRV | NP-SRV) again.
      With state promotion, it would seem that I can 'nix the Common -> Copy Dest, Copy Dest -> Common bits on the copy queue easily enough, but I'm curious whether I could just keep all of my "read-only" buffers and images in the common state and effectively not perform any barriers at all.
      This seems to be encouraged by the docs, but I'm not sure I fully understand the implications. Does this sound right?
    • By NikiTo
      I need to share heap between RTV and Stencil. I need to render to a texture and without copying it(only changing the barriers, etc) to be able to use that texture as stencil. without copying nothing around. But the creating of the placed resource fails. I think it could be because of the D3D12_RESOURCE_DESC has 8_UINT format, but D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL enabled too, and MSDN says Stencil does not support that format. Is the format the problem? And if the format is the problem, what format I have to use?

      For the texture of that resource I have the flags like: "D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET | D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL" and it fails, but when I remove the allow-stencil flag, it works.
    • By ritzmax72
      I know vertex buffer is just another GPU resource represented by ID3D12Resource, but why is it said that vertex buffer don’t need a descriptor heap??
      Other resources like depth/stencil resource, swap chain’s buffer need to have descriptor heaps. How does these resources differ from vertex buffer.
  • Advertisement
  • Advertisement
Sign in to follow this  

DX12 Compute shader being replaced.

Recommended Posts

Hello once again,

I'm performing a bunch of Dispatch() calls but I'm not getting the correct result out of them. I used the VS GraphicsDebuffer , and for some reason, the compute shader of each of the Dispatch call  is the same!

So If I have:

// mat1, mat2 and mat3 have different PSO and RootSignatures

renderPlatform->Dispath(...);  // <- using mat1 compute shader!

renderPlatform->Dispath(...);  // <- using mat1 compute shader!

Could anyone shed some light on this problem? 

I wan't to add a question that may be related with this problem. I'm using this "problematic dispatches" to write to a Resource. So each Dispatch will take a few SRV as inputs and will write to an UAV. Following Dispatches will take the resultant UAV as input (SRV).

Texture FooTex1, FooTex2;
Texture Mat1Out,Mat2Out;

// mat1
Inputs:  (SRV)FooTex1, (SRV)FooTex2
Outputs: (UAV) Mat1Out

// mat2
Inputs:  (SRV)FooTex1, (SRV)FooTex2, (SRV) Mat1Out
Outputs: (UAV) Mat2Out
// etc.

Currently I'm adding (transition) barriers between UAV<->SRV.

Should I add (uav) barriers to make sure writing to the UAV is done? As far as I understand from the MSDN Doc , "all unordered access view (UAV) accesses (reads or writes) must complete before any future UAV accesses (read or write) can begin" I don't need it as I'm not doing further UAV read/write.


Thanks :D 



Edited by piluve

Share this post

Link to post
Share on other sites

I would try capturing your program with another debugging tool to see if they match what the VS graphics debugger is telling you. RenderDoc now has D3D12 support, and there's also the new PIX for Windows (both of which are better than the VS graphics debugger IMO). If they also tell you that the compute shader isn't changing when you switch PSO's, then I would double-check your code for creating those PSO's to make sure that you're passing the right bytecode.

As for your barrier question, if you're already issuing a barrier to transition Mat1Out from UAV->SRV then you don't need any additional barriers. You only need UAV barrier in the case where 1 draw/dispatch writes to a resource through a UAV, and a second draw/dispatch will read from that resource using a UAV descriptor, or if you want ensure that the writes from the second draw/dispatch all happen after the writes from the first draw/dispatch. With no barrier, you have no guarantee that the threads from the first draw/dispatch will occur before the threads from the second draw/dispatch start running, and in fact it's very likely they will overlap to some extent on most GPU's. 

Share this post

Link to post
Share on other sites

Hi @MJP, I´m using the VS Debugger because it is the only one that seems to work fine with DX11on12. I´ll check out the new release of RenderDoc (I think I have an older version).

Thanks for clarifying the UAV barriers, the doc is a bit confusing in that aspect :c

Share this post

Link to post
Share on other sites

I've been investigating this issue again and I think I'm missing some kind of synchronisation. If I leave the first shader as it is and replace the second with a dummy one that just outputs a colour, I see that the second Dispatch now has the appropriate compute shader. 

Maybe I need to do some some kind of GPU-GPU synchronisation? Does the UAV->SRV barrier stall the hole compute dispatch or only the access of the resource? 

I'm running out of ideas :(  


Maybe this pic helps:


I added a Wait/Signal block to discard any issues related with synchronisation. 

Edited by piluve

Share this post

Link to post
Share on other sites

I did some cleaning to the rendering code as I had a lot of remaining DX11on12 code and now I'm able to debug using PIX and NVIDIA Nsight. As far as I can see, it looks like the compute shaders are in place as they should but looks like one SRV is invalid. I have to play around with PIX because I've never used it, so far looks much better than the VSGraphics Debugger :) 

Share this post

Link to post
Share on other sites

I just wanted to give an update on this problem.

I finally solved the issue. First, as I said in my previous comment, I removed all the remaining dx11on12 which was causing PIX and NSight to crash. After that I did some debugging and realised that our rendering API can expect a NULL resource to be set (and I was ignoring it) this caused many problems with the bindings etc. Right now, instead of using null descriptors, I'm setting a dummy texture of size 1 (which seems to work fine). I also found another bug that was affecting the hole thing. During RootSignature creation, the resources are added in order to the signature, but during the binding I was setting them in a wrong order sometimes.

And that was it for this bug.


Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement