Loading several effects with identical blend states with Effects11 causes the Direct3D debug layer to output the following warning in certain scenarios:
D3D11 WARNING: ID3D11BlendState1::SetPrivateData: Existing private data of same name with different size found! [ STATE_SETTING WARNING #55: SETPRIVATEDATA_CHANGINGPARAMS]

This warning seem to be caused by the Direct3D run-time containing some internal deduplication functionality, so that the effect objects ends up sharing the same ID3D11BlendState1 object. This is probably a good idea, but causes the ID3D11BlendState1 object to be named twice from SetDebugObjectName. The second naming generates a STATE_SETTING WARNING #55: SETPRIVATEDATA_CHANGINGPARAMS from the Direct3D debug layer if the effect files have different filename lengths.

One way of resolving this problem is to skip naming the object in SetDebugObjectName if the object is already named.
Closed Mar 9, 2014 at 5:54 PM by walbourn
This is a policy issue for the application and not something that can be resolved within the FX11 library without a lot of extra debug code.


walbourn wrote Mar 9, 2014 at 5:53 PM

This warning is a bit of a nuisance for the debugging layer when using object naming. The only really solid solution is for the application to suppress this warning globally as described in this post, which is what DXUT does for example.

forderud wrote Mar 9, 2014 at 7:02 PM

I believe that patch 15967 resolves this issue within the FX11 library by just changing ~10 lines of code. It would be nice if you could explain why this is not the case if you disagree.

walbourn wrote Mar 10, 2014 at 6:01 AM

You get this warning in many cases if you set the debug name at all. Again, the recommended solution is to have the application silence 'nuisance' warnings as noted in the blog post... This is one of them.

walbourn wrote Mar 10, 2014 at 6:24 AM

To expand on this response: Changing the library (or any library) to try to avoid generating this particular warning is basically a waste of time. There are numerous conditions that result in this message, and it is completely irrelevant to production code behavior. Ideally the Direct3D Debug Layer itself would have been smart enough to avoid ever generating this warning in the first place if the GUID in question is WKPDID_D3DDebugObjectName.

Therefore, the 'proper' solution is for the application (or framework) to just globally silence this silly warning and ignore it in the meantime.