Drilling Down: DX11 And The Multi-Threaded Game Engine
In spite of the fact that multi-threaded programming has been around for decades, mainstream programmers didn't start focusing on parallel programming until multi-core CPUs started coming along. Much general purpose code is straightforward as a single thread; extracting performance via parallel programming can be difficult and isn't always obvious. Even with talented programmers, Amdahl's Law is a bitch: your speed up from parallelization is limited by the percent of code that is necessarily sequential.
Currently, in game development, rendering is one of those "necessarily" sequential tasks. DirectX 10 isn't set up to appropriately handle multiple threads all throwing commands at the GPU. That doesn't mean parallelization of renderers can't happen, but it does limit speed up because costly synchronization techniques or management threads need to be implemented in order to make sure nothing steps out of line. All this limits the benefit of parallelization and discourages programmers from trying too hard. After all, it's a better idea to put more of your effort into areas where performance can be improved more significantly. (John Carmack put it really well once, but I can't remember the quote... and I'm doing too much benchmarking to go look for it now. :-P)
No matter what anyone does, some stuff in the renderer will need to be sequential. Programs, textures, and resources must be loaded up; geometry happens before pixel processing; draw calls intended to be executed while a certain state is active must have that state set first and not changed until completion. Even in such a massively parallel machine, order must be maintained for many things. But order doesn't always matter.
Making more things thread-safe through an extended device interface using multiple contexts and making a lot of synchronization overhead the responsibility of the API and/or graphics driver, Microsoft has enabled game developers to more easily and effortlessly thread not only their rendering code, but their game code as well. These things will also work on DX10 hardware running on a system with DX11, though some missing hardware optimizations will reduce the performance benefit. But the fundamental ability to write code differently will go a long way to getting programmers more used to and better at parallelization. Let's take a look at the tools available to accomplish this in DX11.
First up is free threaded asynchronous resource loading. That's a bit of a mouthful, but this feature gives developers the ability to upload programs, textures, state objects, and all resources in a thread-safe way and, if desired, concurrent with the rendering process. This doesn't mean that all this stuff will get pushed up in parallel with rendering, as the driver will manage what gets sent to the GPU and when based on priority, but it does mean the developer no longer has to think about synchronizing or manually prioritizing resource loading. Multiple threads can start loading whatever resources they need whenever they need them. The fact that this can also be done concurrently with rendering could improve performance for games that stream in data for massive open worlds in addition to enabling multi-threaded opportunities.
In order to enable this and other threading, the D3D device interface is now split into three separate interfaces: the Device, the Immediate Context, and the Deferred Context. Resource creation is done through the Device. The Immediate Context is the interface for setting device state, draw calls, and queries. There can only be one Device and one Immediate Context. The Deferred Context is another interface for state and draw calls, but many can exist in one program and can be used as the per-thread interface (Deferred Contexts themselves are thread unsafe though). Deferred Contexts and the free threaded resource creation through the device are where DX11 gets it multi-threaded benefit.
Multiple threads submit state and draw calls to their Deferred Context which complies a display list that is eventually executed by the Immediate Context. Games will still need a render thread, and this thread will use the Immediate Context to execute state and draw calls and to consume the display lists generated by Deferred Contexts. In this way, the ultimate destination of all state and draw calls is the Immediate Context, but fine grained synchronization is handled by the API and the display driver so that parallel threads can be better used to contribute to the rendering process. Some limitations on Deferred Contexts include the fact that they cannot query the device and they can't download or read back anything from the GPU. Deferred Contexts can, however, consume the display lists generated by other Deferred Contexts.
The end result of all this is that the future will be more parallel friendly. As two and four core CPUs become more and more popular and 8 and 16 (logical) core CPUs are on the horizon, we need all the help we can get when trying to extract performance from parallelism. This is a good move for DirectX and we hope it will help push game engines to more fully utilize more than two or even four cores when the time comes.
Facebook
Twitter
RSS
109 Comments
View All Comments
Mr Roboto - Thursday, February 26, 2009 - link
How about this for the Windows 7 release, a DirectX 9 Halo 2 Port For Windows 7 But Needs it DirectX 11 To Run!OK so there was and still is no reason that Windows XP couldn't have DirectX 10 or DirectX 11 right? These were just more strong armed tactics by Microsoft to force us to hand them our cash for an aborted OS. Like the 4 year old DirectX 9 Halo port that somehow needed DirectX 10 to run, LOL it still makes me laugh. Whoever though up that idea should be shot. Fucking idiots.
So how many DX10 games have been released to this day? Ten? How many have been exclusively DX10 like MS wanted? The answer is one the four year old Halo.
I hope MS continues to hemorrhage money and eventually goes out of business. Nothing would make me happier and it would spur innovation simply by them dying off.
MadBoris - Tuesday, February 10, 2009 - link
Unfortunately the API will not be supported until consoles support it.Consoles now control game development technical design, thx to Microsofts sly ways.
Until next gen consoles come out with the next DX API support then DX9 will still be the standard due to multiplatforming. We can barely get a developer to make the proper PC support changes in their multiplatform games, they aren't going to write seperate render paths unless MS pays them to, like with DX10.
The only redeeming effect is the Nvidia 8800 GPU is one of the best GPU's I bought because it looks like it will last me many years.
vistaisfine - Friday, February 20, 2009 - link
personally i hope windows LIVE grows. they need it to. its a slick system that works well. at least in dawn of war 2 and gta IV. i don't think your assesment of how quickly developers are adopting DX 10 is accurate. Alot of gaming companys go for a wide demographic and that usually means creating content that can scale depending on the hardware. the reason why there are so many dx 9 game is because the lowest common demoninator gamer runs a dx 9 card. People are finshing maxing out their AGP builds. (crazy as that sounds).Mr Roboto - Thursday, February 26, 2009 - link
Are you high? GFWL is an abomination. It has absolutely ruined GTA IV as well as all other games associated with it. It's a straight XBox port and it's total shit. There's no dedicated servers, no anti cheat mechanism, no easy way for matchmaking, constant disconnections, I could go on and on. It's very unfriendly and in typical fashion they treat something as trivial as save games as their own property. Go ahead try backing up your GTA IV save games folder and using them on another PC or game installation. It won't work because Microsoft either didn't think about it or more likely purposefully made it difficult because they think it belongs to them and they're in control of it.The only value GFWL has for MS (which I should have seen coming) is they're going to launch a digital distribution service. Punks. GFWL is so goddamn broken and yet they're going to try to sell games through it before it's even in decent form? Nice. You can bet they'll be ultra slow to in responding to critical bugs and spyware ready made to steal your info on launch day.
Fucking garbage. You're settling for garbage. Valve knows how to do things, development, marketing, listening to their fan base, updating their games above and beyond what any other company would do. Even Steam isn't perfect and I'm not asking MS to become them (an impossibility) but Microsoft has a LONG way to come before they're even in the same conversation.
I hope it crashes and burns even more than it already has because it's ported console junk.
jharper12 - Thursday, February 5, 2009 - link
americunts... that's clever. You got us!! We're idiots! I can't believe we never realized it before! You sir, are pure genius.I just feel absolutely terrible that 43 other countries joined us in our latest war. I feel even worse that the entire world economy was brought down by our financial sector that represents about 1% of our $14.33 trillion GDP... I mean I truly feel awful that we are dragging everyone down with us. I wish I could do something about it, but it seems as though everyone believes "americunts are idiots" and then continues to follow us into oblivion. Sorry about that, I wish there was something I could do to help.
Sincerely,
Americunt
Matrix888 - Wednesday, February 4, 2009 - link
I'll not be bother with the 2000 or so comments here and reply every one of them, but this is my 2 cents about VISTA:1) Drivers issues - there was some initial problem with drivers issues especially old hardware and lazy 3rd parties. But this wasn't MS fault. I've installed VISTA since day 1 and the only problem encountered was an X-FI driver from Creative...which isn't available until like 9 to 12 months later (and it's a beta!!!). Tell me which new O/S doesn't have drivers problem? Win98 was forever plagued with drivers problem, WIN XP suffers similar fate initially, but once the driver matures, it was ok. Hell i've waited for 1 year for an X-FI driver for Ubuntu 7....finally released and the next thing i did is upgrade to Ubuntu 8 (by the time the driver was releasead, UBuntu 8.1 is made available) and it bombs my X-FI.
2) Memory hogging - another urban legend by people who have no ideas. VISTA does not works the same way like XP. What's the point of having idle memory and not used? VISTA pre-cache ur memory to make it better. 2GB of RAM ran just fine.
3) You need a high spec PC for VISTA - BS. I've ran an Atom 330 PC with VISTA Premium with Aero on just fine. Even stress test it by opening tons of apps (including a Virtual PC running XP) and it multitask great with all your everyday apps...MS office, Firefox, e-mails, bit torrent etc....only 2GB RAM.
4) Gaming performance suffers - if you have a moderately new hardware, you are not going to see any difference. I ran my games max settings at 1680x1050. Runs great.
5) UAC? - Cmon. It's only because XP users never use any other OS like Linux or MAC/OS and they can't get this idea in their head it's for their own good. Linux and MAC/OS will prompts u administrator and password when u try to install something or do something funny. It is perfectly fine and u can always turn it off.
So far, i really have minimal problem with VISTA. VISTA MCE makes a great front-end for HTPC and believe this, the start up is MUCH FASTER than XP. Sure a fresh XP will beat VISTA in terms of boot up time, but once you installed tons of apps into it, XP will slow like a turtle while VISTA will have minimal degradtion and you get response to your desktop much faster.
I've finally migrated all my PCs and notebooks last year to VISTA and dump XP forever.
I've no doubt Windows 7 will be great, but to me, it'll be nothing more than VISTA Edition 2. It'll be re-packaging to wow idiots who simply believe all those VISTA rumours without ever using it (or try to run it on a Pentium 3). Seriously, nobody ask you to install a 3.0 engine into a Japanese kei-car!!! :x
For the rest of us, it'll simply be a moderate update of a already fantastic OS.
Hasta La Vista!
volgagerman - Monday, February 2, 2009 - link
One thing that hasn't been stated yet is that the success of any API is directly related to market forces and timing.DirectX 9.0c has been successfull largely for two reasons. One, it took advantage of the market shift that developers would target consoles first and port to PC second in order to extract the largest possible return on investment. Two, many of the gaming engines we enjoy today began their life with the release of DirectX 8. It took 3-4 years for those engines to be built, and they finally meshed with the feature set of DirectX 9, as it was an evolution over 8 and not a true revolution.
DirectX 10 has not revealed any jaw dropping improvements in shipping titles over 9 because developers are still leveraging those engines for exploitation on the console market. They can easily up the visuals for a port to the PC by removing texture compression, upping resolution support and increasing texture sizes, but the major underlying changes to truly support 10 will not happen in the immediate term.
That brings me to my next thought. From everything I've read, the next generation of consoles are targeted for release in the 2011-2012 timeframe. A true next-gen game engine takes at least 4 years to fully bake. That means Unreal Engine 4.0, Id Tech 6, next-gen Gamebryo are all now in development to be ready when those next-gen consoles hit. It's a safe bet they are leveraging DirectX 11 to its fullest. To go one step further, I would guess that market forces are not going to change in the future, and game developers will still target consoles first and PCs second. What that means in the 2011-2012 timeframe is a solid install base of DirectX 11 on even low-end PCs by that point. It would be a no-brainer to anticipate Microsoft leveraging it's latest and greatest API in the next generation XBOX. With market forces and timing in alignment, the next-gen gaming engines and the the next-gen consoles are set to take full advantage of DirectX 11. I will expect nothing less than revolutionary changes to the quality of gaming graphics in that time frame.
Here's one final tidbit. If Microsoft takes Intel's bait and utilizes a 32nm modified version of the Larrabee project for a single chip CPU/GPU solution in the next XBOX, developers will have to shift gears yet again and prepare for a rendering model that is mostly software based. That is beyond DirectX 11 and will lead to even more revolutionary changes...Microsoft would no longer be constrained by the capability of their CPU/GPU, but by the efficiency of the software algorithms to achieve playable frame rates. I look forward to a future on consoles and PCs when a simple patch improves frame rates significantly. No hardware update required. :)
mechBgon - Monday, February 2, 2009 - link
Touching on the "rejected" Vista:Valve's monthly user survey was updated today. WinXP lost 2.48% in just the last month, and Vista has gained 2.47% of that. The ratio of Vista to WinXP is now 1 to 1.91. I guess you could say Vista is "picking up Steam," ;) and rapidly, too.
Ten months ago, this AnandTech thread also indicated (much to the OP's annoyance, I'm sure) that even then, the Vista adoption rate among AnandTech Forum users was already about 50%:
http://forums.anandtech.com/messageview.aspx?catid...">http://forums.anandtech.com/messageview.aspx?catid...
In light of the readership's tastes, also pretty clearly illustrated in the comments here, I suggest calming the anti-Vista rhetoric and not reading more into things than what's really there.
Hrel - Sunday, February 1, 2009 - link
Do you think someone over there at anand could do an article explaining exactly WHY DirectX 10 can't be supported by XP? PLEASE!!!!!!DerekWilson - Friday, February 6, 2009 - link
because Microsoft chose to tie in driver specific features to DX10 that make a retrofit not technically possible. Microsoft could have chosen to spec out DX10 so that new hardware features were exposed while simply allowing for a new driver model, but they did not: they required the new driver model features.this stuff has to do with power management, threading, OS managed/virtual memory, hardware virtualization (sharing between software and even VMs), etc...
Now that what DX10 is eternally locked into existence as is, porting back is not possible. We're in a similar boat with DX11.
There is ZERO technical reason that microsoft couldn't have chosen at the outset to enable the Geometry Shader, to extend const/register limits, and to do all the other things that game developers actually use on Windows XP. It would have required hardware companies to implement a distinct WinXP DX10 driver and Vista DX10 driver, but now that can't be done.
The /why/ of no DX10 on XP is that MS simply decided not to make that an option when developing DX10 and built in features extraneous to game development that require the Vista platform.