Direct3D 11
Note first of all that the changes presented here concern Direct3D 11, even though you’ll often hear reference mistakenly being made to DirectX 11. Here we will use the term Direct3D, but current usage means you’ll commonly find the term DirectX 11 used to refer to the same thing.
While Direct3D 10 was an opportunity to set down some new principles, Direct3D 11 starts bringing them into effect. On the menu, some major innovations and, once again, support for all generations of graphics card. This was THE black spot of the current API and Microsoft got the message.
Therefore, Direct3D 11 will be available for Windows Vista. In fact it is already available as long as you activate this update via a script to get it to appear in Windows Update. It will also be compatible with Direct3D 10 cards… and DirectX 9. Microsoft is anticipating and encouraging a massive change up from Windows XP to Windows 7 by gamers who didn’t bother with Vista. For this, Microsoft has had to redevelop a new API that is compatible with Direct3D 9, which was elaborated from Direct3D 10. Microsoft has made the features equivalent to the old ones so as to take some of the load off graphics cards manufacturers who wouldn’t have been happy to support costly development for old products. With Direct3D 11 it will therefore be possible to use DirectX 9 cards both with Direct3D 10 and Direct3D 11. Here are the 6 feature levels supported by Direct3D 11:
D3D_FEATURE_LEVEL_9_1: Direct3D 9 level and basic shader 2.0, designed for integrated Intel chipsets and GeForce FXs.
D3D_FEATURE_LEVEL_9_2: Direct3D 9 level and more developed shader 2.0, designed for the Radeon 9700s and over.
D3D_FEATURE_LEVEL_9_3: Direct3D 9 level and shader 3.0, for the Radeon X1000s and GeForce 6/7s.
D3D_FEATURE_LEVEL_10_0 et 10_1: corresponding to standard versions of Direct3D 10 and with the option of supporting extended formats for buffers via a new driver as well as Compute-on-10, versions 4.0 and 4.1 of compute shaders.
D3D_FEATURE_LEVEL_11: represents full support of all the features of Direct3D 11.
Before describing the three biggest innovations of the new API in detail, we’re going to talk about the smaller ones, which are nonetheless significant. The first is that you can assemble little bits of code to make up the shaders. This is a technique that simplifies the creation of shaders and means that developers don’t have to create a big inefficient shader or thousands of shaders for each particular case.
Next, the API introduces two new Block Compression texture formats, BC6 and BC7, respectively optimised to support HDR (high dynamic range) and normal maps that can’t be compressed effectively with the previous formats.
Multithreading
The first major innovation of Direct3D 11 comes with multithreading, supported for the first time at API level. Currently most of the 3D engine is made up of a single thread for the renderer, with smaller threads for physics, sound, the AI and so on. The graphics driver can sometimes find multithreading opportunities, but they’re limited. With the new API it will be possible to distribute the rendering engine across multiple processor cores. To enable this Microsoft has introduced deferred rendering on top of the immediate context mode.
Don’t confuse this with the deferred rendering engines used in certain games such as S.T.A.L.K.E.R. as in this case it refers to a rendering technique.
With Direct3D 11, first the command buffer is filled and then it’s processed and you can parallelize the two stages. Ironically this could be seen as a return to the early versions of Direct3D which were generally criticized. In practice however, here the API itself takes charge of everything quite transparently, while improvements in the GPU make this method even more effective.
In more detail, you can use many small independent threads to fill the command buffer. Microsoft has made sure that developers don’t have to worry about most of the problems of synchronisation between threads, which is the most complex part and a break on multithreading. Using this deferred rendering mode does however have a cost that won’t be justified without the use of several threads.
We tested this on a Radeon HD 4890 with a demo supplied by Microsoft in its SDK and which works on all Direct3D 10 cards. This represents a scene limited by the CPU,
- Rendering in immediate context mode: 55 fps
- Rendering in deferred context mode, not multithreaded: 48 fps
- Rendering in deferred context mode, multithreaded: 78 fps
Tessellation
At last! After numerous hesitations and retractions on the development of each new API, Microsoft has now included tessellation. To recap, this is a technique that allows you to adjust sub-division of polygons, usually triangles, so as to add geometry detail. This might seem simple but is in fact more complex because of the numerous division methods, proper placement of the small new triangles and varying levels of detail (LOD).
As of the Radeon HD 2000s all ATI GPUs have had a fixed tessellation unit. The problem is that in order to be able to use it flexibly, you need to use various techniques and several rendering passes, which isn’t always very practical. Indeed, the unit hasn’t ever been used before. With Direct3D 11, on top of the fixed tessellation unit, Microsoft has added 2 new types of shader to drive it. The first, the Hull shader works on data preparation, calculating the tessellation factor (the sub-division more or less) and the control points needed to make up a more detailed mesh later as the tesselletion unit takes care of simply dividing the triangles into smaller triangles. They therefore remain “flat” which in itself contributes nothing. The tessellation factor, which needs to be specified for each side of each triangle is important for level of detail. If it is fixed, too many small triangles may be generated that would massacre performance because, on top of the additional load due to quantity, the pixel shaders handle minimum 2x2 pixel blocks, which is why you need to use adaptive tessellation algorithms.
The second shader, the Domain shader, deforms the mesh to take advantage of the more detailed geometry. Several techniques are possible depending on what the developer wants to do, which is the reason for using programmable shaders. For example the Domain shader can be used to round, smooth surfaces. In this case it uses control points from the Hull shader as a reference for rounding the mesh. You can also use a texture to carry out displacement mapping and add real geometric details instead of simulating them with bump mapping. This is a technique we’ve been talking about for many years and which is finally becoming a reality.
Compute shaders
The final significant innovation introduced by Direct3D 11 is known as the compute shader or DirectCompute. This is a new type of shader that allows you to use GPU processing power for general computing, above and beyond the standard 3D rendering pipeline. Crudely speaking, this is Microsoft’s version of OpenCL. Compute shaders have the advantage of being standardised and therefore directly supported on all compatible graphics cards, contrary to OpenCL which leaves all doors open. The other advantage, mainly in version 5.0, is that they have been designed to interact efficiently with a 3D scene in DirectX, which simplifies usage for physics calculation or non-polygon geometry or even post processing effects. These are currently processed by a pixel shader but this isn’t always very efficient. Compute sharders will therefore improve performance for this type of effect.
To facilitate their introduction Microsoft hasn’t only added compute shaders at 5.0 but also 4.0 and 4.1, so as to give support on DirectX 10 and 10.1 generation graphics cards, with a few limitations of course. Looking at NVIDIA cards, all GPUs since the GeForce 8s have been compatible with compute shaders 4.0 since the 190.62 drivers, while with AMD, only the Radeon HD 4600s and 4800s will be compatible at 4.1, if AMD develop such drivers. The Radeon HD 2000s, 3000s and 4300s/4500s won’t be compatible as they don’t have shared memory between threads executed within the same group.
