Hi Everyone,

I met a strange problem with ID3D11Device::CreateDepthStencilState(). The returned state object did not carry the correct states I set. So I got very abnormal rendering result.

I found the problem with PIX, and then wrote the following test code to verify it:


HRESULT hr = d3dDevice->CreateDepthStencilState( &desc, &d3d11DepthStencilState);

if( FAILED(hr) )
{
PopError( "Failed to create depth-stencil state object!" );
}

D3D11_DEPTH_STENCIL_DESC newDesc;
d3d11DepthStencilState->GetDesc(&newDesc);

static int errorCount = 0;

if (newDesc.DepthWriteMask != desc.DepthWriteMask)
{
++errorCount;
}


And the DepthWriteMask was different between the desc and newDesc sometimes. In my specific case, the desc.DepthWriteMask == D3D11_DEPTH_WRITE_MASK_ZERO and newDesc.DepthWriteMask == D3D11_DEPTH_WRITE_MASK_ALL. It was the same behavior I saw with PIX.

The document just mentioned that:

4096 unique depth-stencil state objects can be created on a device at a time.

If an application attempts to create a depth-stencil-state interface with the same state as an existing interface, the same interface will be returned and the total number of unique depth-stencil state objects will stay the same.

[/quote]

But I could not believe that's the problem since the same depth-stencil-state object should only be reused when the state was the same. And hr == S_OK when the if() triggered.

How could this behavior be explained?

Thank you very much

I am experiencing the same problem, have you found a solution for this?

Ok I have discovered that even though ID3D11DepthStencilState::GetDesc() is returning incorrect values rendering still behaves as expected per the values passed in at creation. It should be noted that PIX will also report incorrect values, presumably because it's calling ID3D11DepthStencilState::GetDesc().

Do you have depth enable set to false? If so, that would explain what you are seeing.

Do you have depth enable set to false? If so, that would explain what you are seeing.

Yes, that was exactly the problem.

Actually, I think it's a bug in D3D 11 documentation which mixed the conception of "enable depth testing" and "enable depth buffering". The real meaning of D3D11_DEPTH_STENCIL_DESC::DepthEnable is the same as D3D9's D3DRS_ZENABLE.

I have already submitted a bug to Microsoft and hope they will fix that in the future DX releases.

I am also seeing this, when I was using nVidia Parallel Nsight to debug my application. Seems that D3D11_DEPTH_STENCIL_DESC::DepthEnable and D3D11_DEPTH_STENCIL_DESC::StencilEnable are "short-circuiting". I also commented on the bug report "[D3D11] Documentation problem in D3D11_DEPTH_STENCIL_DESC.DepthEnable" at Microsoft Connect (requires live account to view... duh MS!)

Note that PIX, Parallel Nsight and manually calling ID3D11DepthStencilState::GetDesc will all return the same data that is "inconsistent" to the states you set, if you had specified DepthEnable = FALSE or StencilEnable = FALSE, but as far as I can understand, it is ok, since those states don't have any effect.

Since there probably doesn't exist a Direct3D team anymore (nobody's been active at MS since December 2010!) to work on fixing the bugs, I have also added a comment to the documentation of D3D11_DEPTH_STENCIL_DESC itself, so people won't waste time scratching their heads on this one, like I did.