The problem with using a deferred context in a single threaded system is that you are doing more work per core in that situation; you have to prepare the CL, which takes some extra CPU overhead as the driver needs to do things and then you have to reaccess it again to send it to the card properly. Spread across multiple threads the cost-per-setup drops significantly and, if you batch them, your send arch will benifit greatly from code cache reuse (and depending on how it's stored maybe some data cache too).
<snip>
(Also, as a side note, I do recall reading that 'create, store and reuse' isn't an optimal pattern for command lists. The runtime isn't really setup for this case and it assumes you'll be remaking them each frame, which is a fair assumption because as you can't chain them together to adjust each others state and most command lists will change each frame in a 'real world' situation it is best to test against this)
Thanks Phantom, but in my case I was thinking of creating the command list once and then executing it for each frame.
As I'm sure you know, a command list containing a constant buffer will only contain references (Or pointers) to the constant buffer and not the actual data containined int he buffer itself, so an app can still change the data in the constant buffer from frame to frame without having to create a new command list.
So for example I was thinking:
1. At startup create a command list (DrawTankCL) that draws a Tank at a position defined in a Contant Buffer ("TankCB")
2. Update TankCB.position on the CPU based on user input, physics etc
3. ExecuteCommandList(DrawTankCL)
4. Repeat from step 2.
As you can see the command list is created once and executed over and over, and yet the tanks posiiton is still dynamic.
Its a shame that this "create, store, reuse" pattern is not optimised int he drivers.
Anyway, at least now I know the answer so I code my game accordingly.
Thanks for your help
Ben