Jump to content
  • Advertisement
Sign in to follow this  
DustinB

D3D12 - Root Signature difference between PSO and CmdList ?

This topic is 986 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

When creating a PSO we must specify a Root Signature

D3D12_GRAPHICS_PIPELINE_STATE_DESC psoDesc = {};
psoDesc.pRootSignature = rootSignature.Get();
// fill out other fields ...

.

And again we must specify a Root Signature before recording commands into a CommandList

commandList->Reset(commandAllocator.Get(), pipelineState.Get());
commandList->SetGraphicsRootSignature(rootSignature.Get());

.

The weird part is that the same PSO is used in calling Reset on the CommandList, meaning the CommandList should already have access to the PSO's Root Signature.  If one does not set the CommandList's Root Signature explicitly, then a D3D12 Error is generated due to undefined behavior.  I suspect this design was put in place so that the CommandList could override it's parent PSO's Root Signature with a different one, but I have not yet tested this to see if this is the case.  Anyone have information on this?

 

Seems weird that we need to set a Root Signature at all in the PSO if we have to then set the same Root Signature again in the CommandList using said PSO.

Edited by DustinB

Share this post


Link to post
Share on other sites
Advertisement

The root signature needs to be set before you draw or dispatch, but you can reset a command list with a null pipeline state if, for some reason, you don't know which pipeline state you're about to use. The command list can change both the rootsig and pipeline states multiple times if it wants.

Edited by Dingleberry

Share this post


Link to post
Share on other sites

Thanks for the clarification.  Indeed, this seems quite flexible.

 

 


The PSO doesn't have to remember this information -- it uses this information to compile/optimize the new PSO, and then is able to forget that pointer

 

I'm not sure what you mean by this.  Of course we can always reuse the the first PSO's descriptor by changing its root signature and using it to create another PSO.  Looking at the ID3D12PipelineState interface, there does not seem to be a way to change a PSO's root signature post creation.  Is there anyway a PSO can explicitly "forget" its root signature, or is this simply due to the internal representation of a PSO?

Edited by DustinB

Share this post


Link to post
Share on other sites

No, a PSO can't change which root sig that it's compatible with after it's been created.

 

What I meant is that the PSO doesn't necessarily retain that pointer. When creating a PSO, it will use some information that's contained within the root signature, but it doesn't retain a pointer to the root signature itself.

e.g.

struct RootSig { int c; }
struct PsoDesc { int a, b; RootSig* root; };
struct Pso { int a, b, c; }
Pso CreatePso( PsoDesc& desc )
{
  Pso newPso = { desc.a, desc.b, desc.root->c };
  return newPso;
}

Share this post


Link to post
Share on other sites
It's similar to dx11 input layouts which need vs byte code -- the input layout doesn't actually hold onto the vs, but it needs to know how to transform vertex data for the vs.

The input layout and vs are in the same place now, but other things like render target information are in the rootsig. The PS might need to transform data based on render target format, eg rgba8/32? Dx11 likely did this lazily when you drew something for the first time, dx12 does it explicitly.

Share this post


Link to post
Share on other sites

Your question is answered in detail in this video: Resource Binding in DirectX 12 (pt.2)

 

In short, when you create a PSO, the RS is only used for validation and PSO compilation (it tells the driver how resources are provided to the PSO).

Edited by zalbard

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!