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?
1
Deferred contexts and inheriting state from the immediate context
Started by dreijer, Oct 25 2012 08:39 AM
3 replies to this topic
Sponsor:
#2 Members - Reputation: 3828
Posted 25 October 2012 - 10:16 AM
ID3D11DeviceContext::FinishCommandList: http://msdn.microsoft.com/en-us/library/windows/desktop/ff476424%28v=vs.85%29.aspx
Immediate context state is cleared before and after a command list is executed. A command list has no concept of inheritance.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#3 Members - Reputation: 128
Posted 25 October 2012 - 06:45 PM
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.
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.
#4 Members - Reputation: 3828
Posted 26 October 2012 - 03:33 AM
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.
A fault with the documentation is that info like this does tend to be scattered around, sometimes in the oddest places, yes.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
