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
ssj4Gogeta - Saturday, January 31, 2009 - link
"DX11 offers nothing new over DX10, as quoted in the article its just a strict superset that builds on and adds features to DX10 capability."aren't you contradicting yourself? :)
chizow - Saturday, January 31, 2009 - link
Oh right, that should read nothing new with regards to hardware requirements. They could've just as easily added the features and called it DX10a or DX10.2 etc....FesterSilently - Saturday, January 31, 2009 - link
Hrm...all I really pulled from this article was:- "...the rejection of Vista" pg. 1
- "...no one knew how much Vista would really suck" pg. 2
- "...slow adoption of Vista" pg. 3
- "...ends up being a more expensive Vista in a shiny package" pg. 3
- "...because of Vista's failure" pg. 7
- "...as Vista still sucks" pg. 8
- "...better upgrade option for XP users than Vista" pg. 8
Oh, yeah! And:
- "...DX 11 looks to rawk" (my quote)
Well.
I'm glad we cleared all that up. Now where's that XP disk...?
:/
ssj4Gogeta - Saturday, January 31, 2009 - link
Sorry for posting this again, but Derek, have we had any more news on Larrabee? Weren't the first samples supposed to be ready by the end of 2008?I also read somewhere that Intel bought Project Offset to use their technology in the launch title for Larrabee.
scruffypup - Saturday, January 31, 2009 - link
Interesting there is still the bashing on Vista,..Some say it "sucks"
Answer this:
Does Vista do everything Xp does? YES
Does Xp do everything Vista does? NO
So how can you say Vista sucks in comparison to XP? The driver issue? That has happened on most releases of Microsoft operating systems and is not the fault of the operating system? The fact old software does not always work on it? That again is not the operating system fault,.. the software was written for a certain operating system,...
Security? I think we all know that Vista is inherently more secure
Performance? Does a new software package (OS, driver, game) always mean better performance,... most often NO!!! GAMES especially,.. they do more,... but are bigger resource hogs,... most drivers you can say the same,...
I feel that Derek's article was unprofessional and filled with a bias which will lead me to steer clear of his future articles,... and ESPECIALLY any opinions he wants to chime about,... sorry to see the Anandtech site have such "craptacular" articles that "suck"!!!
MightyDrunken - Wednesday, February 4, 2009 - link
To love or hate Vista - either way is an opinion. For me there is no correct answer regarding Vista. If the article writer is not allowed an opinon which disagrees with some of it's readers then AnandTech articles will be worthless.I use Vista daily and my impression is it sucks, sorry.
On a two year old dell its slow, very slow(2 Gig RAM, Dual Core duo). All drivers are up to date. My slower windows XP machine was much faster.
The only improvements with Vista I notice are the breadcrumb trail in Explorer and search on the start menu.
Those improvements are not worth 13+ gigs of files and a fairly recent computer. Someone will pipe up and say, "Oh but hard drives are cheap", but what if I want to backup my install to DVD, memory stick...?
Vista is pure bloat. Lets hope the Windows 7 hype is not as misleading as Vista's hype before release.
epyon96 - Saturday, January 31, 2009 - link
Suffice to say the article does not have the flair of Anand Shimpi but it was educational. The Vista comment was unnecessary and seemed out of place.You kept emphasizing how Dx11 is a superset of Dx10. I am wondering why Microsoft just named it Dx10.2 or something of that nature to indicate the superset nature of it? What is the fundamental difference between a 1 and 0.1 or 0.2 advancement in Direct X technologies.
bigsnyder - Saturday, January 31, 2009 - link
I think many of you are trying to interpret what you want to hear from his Vista comments. Bottom line, it is his article, he can say what he wants. I would say that there is far more people agreeing with his comments than what is posting here. There is no denying the fact the Vista did not live up to its hype at launch. Sure, XP had teething problems as well, but the difference here is that XP does offer a significant reason to upgrade over its predecessors win98/ME (w2k was a different market segment). Outside of DX10, what does Vista offer that I should be compelled to upgrade? Vista does not offer that same compelling reason. The current state of Vista is almost irrelevant (I'm sorry, but even with the improvements, Vista still does not paint a rosie picture). The damage is already done. Why do you think MS is accelerating Windows 7 development? Derek, thank you for your honest perspective.Intelman07 - Saturday, January 31, 2009 - link
Urgh Vista bashing from Anandtech...Vista simply does not suck.
bobvodka - Saturday, January 31, 2009 - link
Ok, lets cover a few things with one post;1) Vista "sucks".
I find this claim today intresting; 99% of those I know who have used Vista have seen it as a large improvement over XP, myself included, and those who haven't generally have low spec or unsupported hardware. I've used Win3, 3.11, 95, 98, 98SE, ME, 2K, XP, XPx64 and now Vista and out of all of them Vista has been the smoothest OS I've had from day one (this was March 2007 when I accidently killed my XPx64 install by not paying attention) with the only troubles being 3rd party drivers (such as Creative's inability to write drivers which work first time out and NV apprently forgetting how to write them for around 9months in 2007).
So, Vista far from sucks, what Vista suffers from is being bashed left, right and center even before it was released by 'tech sites' who brought into the whole 'Vista sucks' thing and continued the myth. I can only assume this is because you get better readership from saying something of MS's sucks rather than 'hey, it isn't perfect BUT...' type thing. Hey, that's journalism all over I guess.
2) Vista's development time
This was always going to be a problem for MS. XP was built upon Win2K, indeed they share the same driver model, which was built upon NT and the 9x kernel (in places) so it had a very long development history behind it. Vista had a whole new design thrown at it, new driver model, improved security model etc etc; this stuff doesn't happen quickly nor cheaply. The fact it had such a major overhall and worked so well out of the gate is nothing short of impressive.
The problem however is that many of these changes are 'under the hood'. All the end user sees is a new shiney interface and wonders 'why did this take so long?'. Now, I guess MS could have tried to explain this to the ordinary person, much like they did to technical people, however I suspect this would have been a waste of time because all average Joe User cares about is if it will run his stuff.
(side note: this is something MS really don't get enough praise for, the mindbending amount of work they put in to maintain backwards compatbility between their OS revisions. Take program written for Win95 and chances are it'll work just fine in Vista, THATS impressive.)
3) DX10 and the performance quest
This is another one of those things were people needed more information than they were given to understand whats going on here. The simple truth is, yes, DX10 allows you to write programs which use the GPU better and reduce CPU overhead (this reduction was infact a major part of the performance they were talking about, however everyone assumed when they said 'performance' they meant 'frames per second'); however this would require writing DX10 code, not naively port their DX9c code across and hope everything works out. The problem is this cost time and money, and with the major 2 consoles being DX9 level hardware (more or less) anything which needs to be crossplatform isn't going to have 'shiney DX10 renderer' high on their 'todo list'. (site note: the PS3 doesn't use OpenGL, it has an OpenGL|ES library but anyone with any sense codes to Sony's own graphics library instead).
Of course, once these DX10 renderers are done they add more things to the scene as well, be it particles or general increase in the level of detail. So suddenly you are getting more things on screen for around the same cost in many cases.
End of the day however the DX10 API IS a better API than DX9c and OpenGL; OpenGL did have the chance to 'catch up' but with the dropping of Longs Peak and the release of OpenGL3.0 they threw that away. (personal note; I'd used OpenGL since 1999, however that dropping of the ball made me move away from it).
4) DX11 on XP.
Not going to happen.
Cost and development time don't make it worth while; unless ofcourse everyone was prepared to pay $150+ for an upgrade, because it makes no financal sense to even consider doing this for free and at that cost, well, you might as well get Vista or Windows7.
5) DX11 and Multi-threading
I was at the XNA Gamefest 2008 in london and I'm 99% sure that the multithreaded stuff DOESNT require a driver update. Granted, you'll get better performance with one but the runtime itself can deal with it.
(As for who I am; I work as a programmer for a UK based games company. I wrote the chapter on GLSL for More OpenGL Game Programming and I've been coding now for over 15 years on various pieces of hardware. Just incase you felt I was some newbie :))