Introducing DirectX 11: The Pipeline and Features
This is DirectX 10.
We all remember him from our G80 launch article back in the day when no one knew how much Vista would really suck. Some of the shortfalls of DirectX 10 have been in operating system support, driver support, time to market issues, and other unfortunate roadblocks that kept developers from making full use of all the cool new features and tools DirectX 10 brought.
Meet DirectX 11.
She's much cooler than her older brother, and way hotter too. Many under-the-hood enhancements mean higher performance for features available but less used under DX10. The major changes to the pipeline mark revolutionary steps in graphics hardware and software capabilities. Tessellation (made up of the hull shader, tessellator and domain shader) and the Compute Shader are major developments that could go far in assisting developers in closing the gap between reality and unreality. These features have gotten a lot of press already, but we feel the key to DirectX 11 adoption (and thus exploitation) is in some of the more subtle elements. But we'll get in to all that in due time.
Along with the pipeline changes, we see a whole host of new tweaks and adjustments. DirectX 11 is actually a strict superset of DirectX 10.1, meaning that all of those features are completely encapsulated in and unchanged by DirectX 11. This simple fact means that all DX11 hardware will include the changes required to be DX 10.1 compliant (which only AMD can claim at the moment). In addition to these tweaks, we also see these further extensions:
While changes in the pipeline allow developers to write programs to accomplish different types of tasks, these more subtle changes allow those programs to be more complex, higher quality, and/or higher performance. Beyond all this, Microsoft has also gone out of its way to help make parallel programming a little bit easier for game developers.
Facebook
Twitter
RSS
109 Comments
View All Comments
DerekWilson - Saturday, January 31, 2009 - link
Hi, thanks for the feedback ... I've already talked the vista issue to death elsewhere in these comments, so I'll skip that, but ...3) You are right that to get the most out of DX10 you need renderer designed for DX10 not ported from DX9. At the same time, there are things that can be done to make DX9 stuff faster by using DX10 capabilities that don't require an engine rewrite. Yes this also requires development time, but it seems developers have opted to put time into adding effects with DX10 rather than increasing framerate. I'm not disappointed with that direction, but performance was an option.
I agree with what you said about OGL.
4) I know it's not going to happen, but it didn't need to not be possible. MS could have designed the API to expose new hardware featuers without requiring the driver model change. DX9 can run on XP or Vista's new driver model for example. They chose to make it so that it was impossible to back-port rather than designing DX10 (and subsequent versions) to be tied to the driver model. OpenGL exposes most of the featuers of DX10 to WinXP and all of the things that are interesting to graphics programmers).
5) You are right -- it's not required to support multithreading but it is required if you want a performance benefit from that multithreading.
bobvodka - Saturday, January 31, 2009 - link
Well, to be fair, many of my comments were directed at others in the thread :)4) The thing is, OpenGL and DX9, specifically D3D9, live in different places. D3D9 had alot more kernel side code which caused expensive switches when issuing certain commands; this is why D3D9 got all that instance draw stuff and OpenGL didnt, because on small batch sizes OpenGL could be between 2.3x and 1.4x quicker at executing the draw call then D3D9. OpenGL sits the otherside of the kernel calls and gives the implimenters more control on when that switch occures. D3D10 also sits the other side, again not wasting that time.
There were also changes in the resource model, the driver model and various other areas; some of which were to make the Vista windowing system possible. This resource model and everything about it was very much tied to D3D10 and how it does things. OpenGL's resource model was also fundamentally different to the D3D9 model, with again the implimenter having alot more control; you never suffered a 'lost device' in OpenGL for example and the runtime automatically controlled allocated memory unlike in D3D9. There are some things OpenGL could do which D3D9 couldn't as well; such as on-card async memory copies and render-to-vertex buffer (well, ATI had a hack for it but the OpenGL method was cross-hardware).
Could they have done it? Well, of course they could have done but unlike previous DX updates it would have taken alot more effort, time and money. All for a, at the time, 5 year old OS they were hoping to begin getting rid of.
Personally, I think this was a good move all in all, the problem was with how it was presented to the general masses who suddenly saw they had to pay a few 100 USD for a new DX version.
Dribble - Saturday, January 31, 2009 - link
The reason all our games are DX9c are because that's what the consoles support (yes I know PS3 uses open GL, but it has 9c feature support - basically has 7800GTX in it).Most games are made for console as well as PC, the majority use some cross platform renderer (e.g. unreal 3 engine) and that will support DX9c. Cross platform DX support won't change until the Xbox 720 and PS4 arrive.
I don't see how DX11 will change this?
DerekWilson - Saturday, January 31, 2009 - link
That's a really good point and something I should have considered.I think the gap in performance between the PC and consoles will so heavily favor PCs that it will inspire developers to once again shift their focus to the PC. I could be wrong though.
ssj4Gogeta - Sunday, February 1, 2009 - link
That will change if Microsoft choose Larrabee for XBox 720. Cause then it will support all the DirectX (even unreleased) versions and all the OpenGL versions. If MS chooses Larrabee, and it also becomes popular for PC gaming, we PC gamers may see a huge benefit because then the games will be built for the latest DX version.bobvodka - Sunday, February 1, 2009 - link
It's all well and good saying that but Larrabee is currently utterly unproven technology.Don't get me wrong, I'd like to see it do well if only because 3 players in the GPU race will be better than 2 from a technology and consumer stand point, however everyone seems to be pinning their hopes on this technology when there hasn't even been a working demo of DX9 at the same speed as NV/AMD, never mind DX10 or DX11.
ssj4Gogeta - Sunday, February 1, 2009 - link
You're right. But I'm really excited. It would be so nice if Intel can really pull off such feat. we'll have 2 TFLOPS of general purpose parallel processing power!bobvodka - Saturday, January 31, 2009 - link
The problem is, the consoles is where the money is. Combine that with a fixed hardware platform (well, hard drives and different screen sizes not withstanding) it makes for a much easier time for devs.piroroadkill - Saturday, January 31, 2009 - link
That's definitely a good point. Any game engine these days has to support the major consoles for it to be successful - even if that only means the 360, you're still hamstrung by DirectX9, regardless of whether XP has it or not.From a personal point of view I'm still running XP because I run a clusterfuck of graphics cards that vista would shit the bed thinking about.
William Gaatjes - Saturday, January 31, 2009 - link
"Many under-the-hood enhancements mean higher performance for features available but less used under DX10. "I must be remembering it wrong but the same thing was sad about dx10. However it turned out to be nothing more then getting people to buy vista. I wonder how much will come true this time.