Did deferred contexts/driver command lists end up mattering?

[Red Hawk]

With the presence of Mantle and the upcoming release of DirectX 12 and Vulkan, it looks like DirectX 11's time is over. Yes, there will be a DirectX 11.3 available to developers who don't want to go to the trouble of coding close to the metal with DX 12, but all the developers who really focus on delivering the best, most advanced and detailed visual experience are set to be using the close-to-metal APIs.

So it makes me wonder. When DirectX 11 first came out, there was talk about how it would make multithreading easier than DirectX 10. From what I can tell, that multithreading was supposed to come from a feature called "deferred contexts" or "driver command lists". The feature never gained much use -- I think Civilization and Assassin's Creed games were a couple of the few that used them? I'm not entirely sure though. Not only did games not widely support it, but from what I've read AMD never enabled it in their drivers. Nvidia did, though, which is why the feature was enabled in some Nvidia-sponsored games. I've seen criticism of AMD on this forum for never supporting that feature. But looking back, did the feature really matter? It didn't grant Nvidia a decisive advantage in Civilization V, if indeed Civ V did support deferred contexts. Developers weren't exactly chomping at the bit to support it and pressuring AMD to enable support for it.

My guess is, the reason driver command lists never caught on with developers or AMD was because it wasn't worth the trouble. The performance benefits didn't warrant the complexity and effort it took to get the feature to work. AMD and developers like DICE were looking past deferred context to the more effective solution of an API that is closer to the metal altogether.

So, what do you all think? Was it a mistake for AMD to never enable driver command lists, or was their choice to avoid expending development resources on it and instead put their focus on upcoming close-to-the-metal APIs a wise one?

 

[96Firebird]

Ryan Smith posted about this topic a while back, in a very well-written and informative post.

Basically, because it was an optional part of DX11, adoption of the feature never caught on. As to why more games didn't use it, that is anyone's guess. Some could say because AMD didn't support it, it would neglect those users. Other could say the feature was too hard to implement and wasn't worth it. Face it, most games aren't CPU-limited, where this feature shines. You'd have to ask the developers why they chose not to support the feature...

Interestingly enough, Ryan assumed (per the post above) that AMD was close to supporting multi-threaded rendering in their drivers back in 2011, but that never happened. Also, his last line in the post talking about AMD wanting to bypass DX11 altogether, turns out that is exactly what they did. And this was over 2 years before Mantle was ever announced...

 

[Red Hawk]

Ryan Smith posted about this topic a while back, in a very well-written and informative post.

Basically, because it was an optional part of DX11, adoption of the feature never caught on. As to why more games didn't use it, that is anyone's guess. Some could say because AMD didn't support it, it would neglect those users. Other could say the feature was too hard to implement and wasn't worth it. Face it, most games aren't CPU-limited, where this feature shines. You'd have to ask the developers why they chose not to support the feature...

Interestingly enough, Ryan assumed (per the post above) that AMD was close to supporting multi-threaded rendering in their drivers back in 2011, but that never happened. Also, his last line in the post talking about AMD wanting to bypass DX11 altogether, turns out that is exactly what they did. And this was over 2 years before Mantle was ever announced...

You know, Nvidia may have assumed that deferred context was what gave them the advantage in Civilization V, but I'm not sure that's the case. Benchmarks showed the advantage only existed for Fermi vs Terascale (AMD's VLIW5/4 architecture), not between Kepler and GCN. In fact, AMD held the advantage in Civ V with GCN over Kepler, at least in Anandtech's 2012 benchmark suite. Both advantages may have to do with DirectCompute texture decompression performance. Terascale was a slouch at it, with the 6970 only matching a 560 Ti, as was Kepler, with the 680 only brushing up against the 7870. Kepler's performance is even more disappointing compared to Fermi, as the 680 actually loses to the 580. If you look ahead to Anandtech's 2013 Civ V compute benchmarks, Nvidia apparently improved performance via driver optimization. If that was the bottleneck, you'd expect general Nvidia performance to improve significantly as well. And it does, with Nvidia taking back the lead, though not as decisively as Fermi held the lead over Terascale.

If deferred contexts was truly the feature that enabled Fermi to blow past Terascale in Civ V performance, and deferred contexts still wasn't enabled for GCN but was for Kepler, shouldn't Kepler have kept the lead over GCN? So yeah, especially in the context of what Huddy said about display lists (same thing as driver command lists) in that interview with bit-tech that Ryan references, it seems like there wasn't all that much of a performance benefit granted by deferred contexts to make supporting it worthwhile. Even in games with it, it didn't ensure Nvidia's success. It makes sense to me that AMD chose to pass on supporting the feature and instead was putting effort into Mantle and pushing the industry toward the better solution of close-to-metal APIs

 

[ThatBuzzkiller]

Deferred contexts were useless in DX11 because no pre-patching of the command lists could be applied to them to reduce the submission overhead so the immediate context had to be the one in charge of patching the deferred command lists since it was also responsible for submitting the command lists to the GPU ...