I took my first stab at using deferred contexts in DirectX 11 the other day. My use-case for deferred contexts is probably somewhat different from the common scenario though; I'm interested in rendering a bunch of things on a deferred context, have them executed on the immediate context and then have the API reset the immediate context to what it was before I executed my commands (i.e. basically restoring the render state).

To test this, I created my deferred context using CreateDeferredContext() and then rendered a simple triangle strip with it.

Early on in my test application, I call OMSetRenderTargets() on the immediate context in order to render to the swap chain's back buffer. Now, after having read the documentation on MSDN about deferred contexts, I assumed that calling ExecuteCommandList() on the immediate context would execute all of the deferred commands as "an extension" to the commands that had already been executed on the immediate context, i.e. the triangle strip I rendered in the deferred context would be rendered to the swap chain's back buffer when I executed the generated command list on the immediate context.

That didn't seem to be the case, however. Instead, I had to manually pull out the immediate context's render target view (using OMGetRenderTargets()) and then set it on the deferred context with OMSetRenderTargets().

Am I doing something wrong or is that the way deferred contexts work?

Haha, I've been reading the docs up and down -- even sideways -- and I still missed this. I'm glad somebody else knows how to read. I guess what threw me off is that the paragraph you linked is missing from ExecuteCommandList(), which is where it's most relevant, in my opinion.