Shadowmap resource states with a shared pipeline resource signature (and _com_error for fun)

[RobertMtx]

I'm trying to implement shadow mapping with a shared pipeline resource setup. Basically, every "world based" entity in my game engine uses the same pipeline resource signature. To sample from the shadowmap, I included the shadowmap texture as one of the resources in this pipeline (as Diligent::SHADER_RESOURCE_TYPE_TEXTURE_SRV).

I'm switching my shadowmap back and forth between a render target and shader resource state to get this to work. Something like this..

1. set shadowmap as render target
2. set "shadowmap output" as the world entity shader
3. render all world elements
4. set shadowmap texture as shader resource, and set normal render targets
5. set "normal output" as the world entity shader
6. render all world elements

However, I'm running into a problem at step #3. When I try to execute these pipeline states, Diligent complains about the shadowmap not being in a shader resource state. This is because the shadowmap is registered as a global shader resource in the shared pipeline signature (I believe). The shadowmap vertex shader does not make any use of this resource, but it just being in the pipeline signature is throwing warnings and possibly exceptions. I'm getting another _com_error since implementing this setup, after about 3 frames of getting resource state warnings, I get the _com_error exception and a crash. And wow are these _com_errors hard to tack down. Last time I had one, it was being triggered by the inclusion of dynamic buffers in the shared pipeline resource signature that were not being used, so I'm assuming the pipeline signature has something to do with the _com_error.

Any advice on how to resolve this issue? Will I be forced to create a second pipeline resource signature for shadowmap rendering? It would be a shame, because both of them will be identical, apart from the shadowmap texture.

Appreciate any ideas!

[RobertMtx]

I'm still getting the _com_error, even after removing most of the shadowmap related code, so I'm assuming I've moved something around in a way that D3D or Diligent doesn't like. I always have a really difficult time figuring out the cause of these. If there's any advice on how to go about narrowing down what might be going wrong here, please let me know what I can try.

I'd almost guarantee it is in some way related to dynamic buffers or the pipeline resource signature, or both. Every time I run into this _com_error issue, it always happens at Present(), and is always tied to those elements. I can't seem to find any information that points to an actual problem. I've also tried every which way to catch() the _com_error being thrown, but it never works. My catch() just gets ignored. Really appreciate any suggestions on how to track it down.

[RobertMtx]

After a long fight with my engine, I've at least figured out that the _com_error is unrelated to the shadowmap changes. And it's actually not related to the dynamic buffers or pipeline resource signature. It is related to the render targets. I haven't figured out exactly what is causing the exception, but I think it may be because I tried to store the back buffer render target view into a variable and set it as the target across several frames. After narrowing the problem down to this, I realize that's probably because of double buffering, and the fact that the actual render target is being alternated between two separate textures. But that's just a guess at this point.

Anyway, I'm still curious about the texture shader resource vs render target resource problem. When shaders need to share a pipeline resource, is there a way to exclude a certain resource from certain shader executions? How can I allow these world objects to draw onto the shadowmap without activating this warning about it being in the wrong state?

I'm assuming its not just a hollow warning? What happens when I run shaders with a shared pipeline resource that has a resource in the wrong state? Will it be fine as long as they don't touch that resource?

[RobertMtx]

I actually am explicitly transitioning, both to shader resource state and render state (depth stencil). That's what I meant for steps 1 and 4. But I get the warning during the shadowmap generation stage. The shaders used during that stage don't use the shadowmap as a resource. Actually, they are purely vertex shaders, so they don't even have access to any textures. The pixel shaders attached to the pipeline states for the shadowmap stage have been set to null, using tutorial/sample 13 as a guide.

Would there be any other reason it would complain about it not being in a shader resource state during a vertex-only shader execution that doesn't have access to textures? I'm not experienced with using different render targets and switching textures between states, so I may be doing something the wrong way. But using break points, I can confirm that the output warning pops up during the shadowmap vertex execution stage, which doesn't use any pixel shaders or textures.

Edit: When you say used by the pipeline, do you mean sampled from? While the shadowmap vertex shaders definitely don't use the shadowmap texture, its possible their shader code can still see the variable.

[TheMostDiligent]

Which backend are you using?

[RobertMtx]

DX12, but I'm using the dxc compiler apart from Diligent, then linking up the byte code.

Here is the vertex shader code. Let me know if you'd like to see the entire inclusion branch (all source code):

lerpWorldShadow main(vinNorm vin)
{
	lerpWorldShadow lerp;
	sxattrWorld attr = bufWorld[ vin.AttrIndex ];
	float4x4 world_xform = bufXForm[ attr.XForms ];
	float3 world_pos = mul( world_xform, float4( vin.Position.xyz, 1.0f ) ).xyz;
	lerp.ClipPos = mul( bufEnv[attr.EnvIDS].ShadowTransform, float4( world_pos, 1.0f) );
	return lerp;
}

[TheMostDiligent]

This might be a bug - can you create a small reproducer? E.g. modify shadow map tutorial so that it uses the signature the way you do?

[RobertMtx]

Hold off on doing any further investigating for the moment. After moving some things around, I stopped getting the warning every frame. It only shows up one time now, and I'm suspecting it is because of something I'm doing. I will let you know what I find out. I appreciate the help!

[RobertMtx]

For some reason, I get the warning on the very first frame of rendering shadows, reporting that the shadowmap texture is not in a shader resource state, even though that stage is actually using it as a render target. The warning will never appear again now. However, if I call CommitShaderResources() before setting my shadowmap render target, I do not get the warning. If I try to set my shadowmap render target, then call CommitShaderResources(), I end up getting the warning during the actual CommitShaderResources() call instead of during the shadowmap rendering calls.

I'll be honest. Understanding when I need to call CommitShaderResources() is not something I have a firm grasp of. I don't really understand what this function does, or what actions I need to commit after doing. Is there a tutorial, sample, or documentation that explains specific situations that require committing? Up until now, I've just been calling it at the very beginning of every frame.

But in any case, I don't think there is a bug, but without fully understanding what's happening, I'm not sure. My guess is that I'm committing some random thing that happens on the very first frame. It's even possible something is not rendering correctly on that frame, because it would be difficult to notice.

[TheMostDiligent]

There is no tutorial on this (though every single tutorial actually uses it).
CommitShaderResources() makes resources in the shader resource binding object available to the GPU. Think of it as setting all the right resource pointers. Before you call, the pointers are either null or point to something stale.
You need to call whenever you need to change resources, and also at the beginning of the frame because the context starts the frame in default state.