Original Post
Oct 2, 2011 at 6:13 AM
I'm working with D3D11 and it's fun and all, but I don't really understand Microsoft's decision to split the D3DDevice into device and device context. I just don't see the benefit. This is (at least) partly because I've never really grokked what a context is supposed to represent. The pattern appears to be that that the device is used to create other D3D objects, and then the device context is used to manipulate them. How is that better than keeping it all together?
Oct 2, 2011 at 7:08 AM
An important thing to note is that there's two kinds of contexts: immediate and deferred, so that makes 3 interfaces -- the device, the immediate context, and deferred contexts.
The device controls resource management for all threads.
The immediate context gives one thread direct control over the GPU.
A deferred context gives one thread indirect control over the GPU.
So if you had a multi-threaded renderer, all threads would share the one device, one thread would own the immediate context, and then all other threads would own a different deferred context.
Oct 2, 2011 at 4:05 PM
Ah, that makes sense, now that it's been explained. Thank you.
Oct 3, 2011 at 9:28 PM
Hodgeman basically hit the nail on the head - the design change was done more or less to support multithreading. In the end, by separating the resource management from the operations, it makes it quite easy to implement multithreaded rendering paradigms without imposing the solution on the user. Overall, I am quite impressed with the solution...
Oct 3, 2011 at 10:44 PM
Perhaps that's why I didn't immediately understand it--I've yet to look into multi-threaded programming.