Jump to content
  • Advertisement
Sign in to follow this  
WOsborn

DX12 DX12 - RenderToTexture / CommandLists

This topic is 990 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In DX11 and prior to draw to an off-screen texture (renderTarget) you would do something like this:

dx11_dev_context->OMSetRenderTargets(1, &_color_view, _depth_view);

And any draw calls after that would get sent to that texture until another OMSetRenderTargets() was called.

This allowed a bind() in a high level function and then draw all objects in a lower scene-graph draw().

 

My question is in DX12 how is this type of scenario accomplished?

Does every CommandList need to do a cl->OMSetRenderTargets() call so that if a Draw call is made it knows where to go?

 

Is it and option to:

 

CL0

  Transition::RenderTarget

  OMSetRenderTargets() 

  ClearRenderTargetView

}

CL1

{

  IASetPrimTop

  IASetVertexBuffer

  ....

  Draw scene objects

}

CL2

{

   Transition::Present

}

 

CommandQueue->execute(CL0,CL1,Cl2);

Edited by WOsborn

Share this post


Link to post
Share on other sites
Advertisement

Hi,

 

In general there is no state inheritance between two different direct command lists. It is expected that the full set of states (PSO and non-PSO states) is recorded within a direct command list. There are some options to ease this a bit, initial PSO states can be specified with the pInitialState parameter at creation time (CreateCommandList), if non is specified a default PSO is used instead. All non-PSO states need to be recorded (RSSetViewports, IASet***Buffer, OMSetRenderTargets, ...). 

 

With this in mind, you can try to adapt the way you record the command lists to it. If you split rendering of many objects (of the same render-pass) in different command lists you need to specify the render-states per command list, even though it might seem redundant. So your example from above would sadly not produce the intended behavior. 

 

For bundles the set of rules are of course a bit different. For more info read Graphics pipeline state inheritance

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!