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.

From Evolution to Expansion and Multi-Threading: The Mile High Overview Going Deeper: The DX11 Compute Shader and OpenCL/OpenGL
Comments Locked

109 Comments

View All Comments

  • DerekWilson - Saturday, January 31, 2009 - link

    These figures include "shipped" versions of Vista that people chose to downgrade to XP. It includes systems that came preinstalled, even the "vista capable" systems that people might have chosen to replace with another OS out of the box or after it didn't deliver what they expected.

    No Vista isn't as bad now as it was at first, but that first impression really does matter and significantly affected DirectX10 adoption, development efforts, perception, and all sorts of things that have a lasting impact on the entire industry.

    Also, MS designed DX10 to be tied to the WDDM when they didn't need to in order to expose functionality for developers to use the new features of hardware. They didn't need to do this at all, and we could have had DX10 and DX11 on XP if MS hadn't wanted to push sales of Vista through needless requirements that tied future versions of DirectX to it.
  • michal1980 - Friday, January 30, 2009 - link

    Vista bigger problem was Image. It started a bit rocky, and by the time it was 'fixed' people allready wrote it off. M$ was/is smart enough to know a damaged brand, and instead of releasing Vista Sp2, they slapped a new name on it.

    I do have a bit of a chip on my should about win7, from what I read, i'd love to upgrade.

    But good lord, I own 2 ultimate, and 3 home preimum licenses. I hope M$ has some nice deals for vista users, because i'm going to feel a bit ripped of having an OS with a 2 year life span.
  • frozentundra123456 - Sunday, February 1, 2009 - link

    I agree that it is a ripoff to have an OS with such a short life span. Is the "planned obsolescence" in the worst form??
  • LeStuka - Saturday, January 31, 2009 - link

    I read somewhere that Vista Ultimate owners will get a free/reduced price upgrade.. Not sure how reputable that is (my memory is a bit hazy on it) but is defiantely worth some research.
  • marsbound2024 - Friday, January 30, 2009 - link

    Let me start off by saying I was enthralled by this article. Very well detailed and well explained. There were a few occasions, however, where I wished for more explanation (or maybe my eyes skipped over an explanation you might have provided earlier in the article). I will admit, I am not as highly inclined on software as many people might be here. I am a great deal more interested in hardware usually, but when it comes to APIs such as DirectX and operating systems and their features such as Windows 7, then I am usually engrossed in those. What exactly are LODs and what is OOP constructs and what is HLSL? Now admittedly I can use Google to find all of this out, but it would be nice to have this consolidated into your article (if it was, but my eyes skimmed over that part, then I apologize; though I read your article pretty much word for word).

    There are a few grammatical errors such as instead of "that" you put "than" or maybe it was "then" and you said "a architectures" or something to that effect. This doesn't really matter but I thought I'd throw that out there.

    I'd really like to know if the upcoming generation GPUs in June/July will make use of DirectX11? I suppose this depends on how quickly Microsoft can a good, full-featured SDK out there, perhaps. Also, albeit a bit off-topic, but any thoughts on when Windows 7 might be released to consumers? Are we still thinking later this year in time for the holiday season or the old Microsoft "by the first quarter of 2010" or whatever it was (i.e.: January possibly)?
  • DerekWilson - Saturday, January 31, 2009 - link

    Sorry about leaving out some definitions there ... I went back and added in some explanation of what HLSL and OOP stand for and what LOD is.

    We suspect that the first round of hardware that comes out after Windows 7 is available will support DX11 ... We haven't had confirmation on that from either vendor yet, but that's our strong feeling at this point.
  • michal1980 - Friday, January 30, 2009 - link

    Author just seems to have a huge chip on his shoulder.


    good article, that quite frankly left a bad taste in my mouth because of the unexplained, and un-needed vista bashing
  • tommy2q - Saturday, January 31, 2009 - link

    vista 64 bit has been great for me. it's faster than xp pro on my computer and more stable.
  • DerekWilson - Friday, January 30, 2009 - link

    I don't have a problem explaining myself, I just thought it was unnecessary -- I apologize.

    It's not that I have a chip on my shoulder, it is simply a fact that Vista had and has problems that caused issues with the uptake of DX10. It's not a personal problem, it's just information.

    First, obviously an OS upgrade was required to get DX10. People were turned off to this idea because of initial problems that were resolved after a period of time. But much damage was done.

    For the first year of it's life, many drivers and applications were unstable and buggy, especially sound and graphics and especially under 64-bit Vista. MultiGPU support had its own problems, but that's a whole other barrel of monkeys. When SP1 hit most of our problems were resolved.

    Performance for many tasks are decreased under Vista, though, again, much of this has been fixed. But the problem is that uptake of Vista was damaged because of this, especially among hardcore gamers and especially because there weren't any DX10 only titles or Vista only titles that were compelling (and no, Lost Planet was not compelling). Also, in cases like Crysis, DX10 incurs a huge performance hit and many gamers prefer to run DX9 anyway for the higher performance.

    OS X also made huge strides and is a terrific OS. For usability, people have started to realize they had a choice in large part because Vista failed at the beginning to deliver what it promised. And choice is good.

    MS recognized that they had a problem and implemented and extended again and again downgrade options to Windows XP for customers who were unsatisfied with Vista. They have significantly invested in and sped up development on Windows 7 in order to deliver an option that will regain customer interest. They've also dumped tons of money into ad campaigns like mojave and seinfeld.

    Vista is not a failure in terms of total sales or market penetration as compared to other pieces of software, but it absolutely is compared to other major milestone MS OS releases. They needed to deliver a WinXP and they delivered a WinME ...

    The degree to which people hung on to XP and the problems with Vista have certainly caused a delay in a full transition to DX10 programming by game developers.

    Vista failed to be truly viable vehicle for pushing forward graphics technology on the whole not because it totally sucks, is lame, or any one person doesn't like it. It failed on its merits because it didn't come out of the gate as strong as it needed to be.

    Certainly many developers have done some cool things with DX10. Which is great. But building a platform where people like the Beta more than their current stable OS is a good start to getting people interested in dropping Vista for Windows 7 and inspiring hold outs to finally move from Windows XP to Windows 7.

    I wasn't trying to "bash" vista. I feel like I was just calling it like it is.
  • archer75 - Saturday, January 31, 2009 - link

    All of the "problems" with Vista you mentioned actually aren't even Microsoft's or Vista's fault. Drivers are applications are the responsibilities of 3rd parties. It is they who dropped the ball. Most companies grew up with XP and that is what people learned to write drivers and apps for. With the necessary change to the driver model in Vista these people had to learn a new way of writing drivers. A necessary change but it took time.

    Also everything that SP1 fixed, was fixed long before SP1. All of those updates were available on the knowledge base. All SP1 did was put them in one neat little package. People like myself had those updates long before SP1.
    I also run x64 and have since beta. My system has had quality drivers on day 1 and I never had any stability issues either.

    Obviously an OS upgrade was required for DX10. And why wouldn't it be? Do you give away all of your new features in your old products? What company does that? You put new features in new products. Apple does this. Hell, ilife 09 is leopard only. They force you to upgrade regularly.

Log in

Don't have an account? Sign up now