This project has moved and is read-only. For the latest updates, please go here.
1
Vote

STATE_SETTING WARNING #9: DEVICE_OMSETRENDERTARGETS_HAZARD

description

I'm experiencing problems with DEVICE_OMSETRENDERTARGETS_HAZARD warnings from the Direct3D debug layer. The warning occurs when executing the same effect multiple times in a loop with two textures alternating between being shader-resource (input) and render-target (output). The code manually unassigns the shader-resource texture with a m_effect.GetVariableByName("InputTex")->AsShaderResource()->SetResource(nullptr) call before assigning the same texture as render-target in the next iteration. Still, this shader-resource unassignment does not seem to be "activated". This was not the case with the Direct3D 10 effect library.

The root cause seem to be that a ID3DX11EffectShaderResourceVariable::SetResource(nullptr) call does not immediately result in a corresponding ID3D11DeviceContext::PSSetShaderResources call to unbind the shader-resource. As temporary work-around, I've added the following code at the end of each loop iteration:
ID3D11ShaderResourceView* shader_resource_views[D3D11_COMMONSHADER_INPUT_RESOURCE_SLOT_COUNT] = {};
m_context->PSSetShaderResources(0, ARRAYSIZE(shader_resource_views), shader_resource_views);
This does, however, feel like overkill, since it releases all shader-resource slots.

Could it be possible to extend the Effects11 library to make it possible to unbind shader-resources with immediate effect?
Alternatively, could it be possible to expose the slot index of shader-resources in the Effects11 API, so that it's possible to unbind more selectively?

comments

walbourn wrote Jul 9, 2014 at 12:51 AM

The actual bind slots end up being fairly dynamic in the implementation and not really known until dependencies are checked.

There's two possible workarounds here:

(a) use the debug layer APIs to suppress the warning (see this blog post)

(b) Use Apply() right after manually setting the resource to nullptr.