I am using Direct3D11 / DXGI 1.1 (in feature level 10_0).

I have to create a keyed mutex texture2D to use DirectWrite.

I can do this, and OpenSharedResource and see the texture dimensions in Direct2D.  I can get the IDXGIKeyedMutex on both devices.

However, to illustrate this problem I totally remove the D2D/DirectWrite code, and....

AcquireSync() ReleaseSync() is ok until I do something with the immediate context in d3d11. 

For example, Acquire, ClearRenderTarget, Release will result in this error upon Release...

First-chance exception at 0x75029617 in TestBed.exe: Microsoft C++ exception: _com_error at memory location 0x0a17eeb4..

Subsequent attempts to Acquire will result in -2005270527 .. which translates to nothing on Earth.

Another example, OMSetOutputTargets (to totally different textures) before AcquireSync will trigger AcquireSync to return -2147024809.

This is not per frame.  Once it breaks, it breaks.  There are no real signs of the texture working or clearing to any color, ever, while in this keyedMutex mode.  Otherwise its fine??

I dont know what to think???
Dependency problem???

Why is it being so difficult??

First of all, do you run it on Win7 or Vista with 7IP?

Second, let me make sure my assumptions are correct.

You have D3D10 device (shared with D2D) and D3D11 device with feature level 10_0.
You create a shared resource on D3D11 device and then open it on D3D10 device and it works fine.
Then you call AcquireSync on D3D11 device, call ClearRenderTarget and then call ReleaseSync which has unexpected behavior.

How exactly does it fail, does it return a particular HRESULT value and prints this string in output log or does it actually throw an _com_error expection out of API call?

If yes, any chance you got a minimal repro case?

Thanks!

Windows 7 32 bit, and Visual Studio 2010 beta 2.
I'm also using modified SlimDX, with DXGI 1.1 changes.

The problem above has magically fixed itself, through recompiling or something.

Now I have more issues with this API, but at least now I get some visual results and the AcquireSync return codes are consistent with the documentation, even if they are unexpected/illogical.
1) My KeyedMutex is working. Commenting out all AcquireSync/ReleaseSync and I see nothing.
2) ClearRenderTargetView on my text surface only works the first time - text starts to layer. Clearing possible via D2D maybe, but why is it failing via D3D when AcquireSync is successful?
3) To force the mutex to work as above, I need to call my RenderText function once, immediately after creating my Devices/Swapchain. That must be before I create my render targets, shader resources,depth buffers,cubemaps, etc. Without this strange fix-up, 4 and 5 below apply.
4) When RenderText exists purely in middle of my render loop, I get the following result on first frame - E_INVALIDARG when AcquireSync(0, INFINITE) is called. I will see a _com_error in the debug output.
5) If RenderText is moved to the start of the render loop, specifically before I do OutputMerger/SetTargets, then WAIT_ABANDONED is returned for the D2D mutex (device 1), again first frame. I will see a _com_error on the ReleaseSync(1) just prior.
6) This solution of creating 2 devices seems to cause PIX to just crash.

I do have debug info on, in every case, and see nothing.

Here are some of my functions....

now after that I will lock it to D3D as a shader variable and render a full screen quad, hence the Release(2).




My opinion is the DXGIKeyedMutex definitely needs more debug info as to whats goin on with these _com_errors, and Microsoft should have an example of how to use this with DirectX11.  I have seen the example on codeplex.  I have no clue about COM, but apparently _com_errors have descriptions or something so I will look into that.

thanks.