AMD Radeon HD 3800: ATI Strikes Back

Introduction
Things aren't looking too good for AMD. Up until now, its graphic card offerings were only worthwhile for two cards: the Radeon HD 2900 XT, performing better than the GeForce 8800 GTS 640 MB at a similar price (but at a noise and power consumption level much higher at peak) and maybe the Radeon HD 2600 XT, but only for Home Theater amateurs. Here may have been a big gap between those two cards, but their respective price points were almost coherent. The manufacturer was ready to fill it up with its Radeon HD 3850 and 3870, which only launches today. At least, this was true until, all of a sudden, its best friend knocked the air out of it by launching a card that surprised everyone, NVIDIA included: the GeForce 8800 GT 512 MB with a performance-price ratio that's actually exceptional.



Call of Duty 4
The situation thus becomes particularly ironic today because, AMD's very high end is thus beaten by a card sold at $230 . It's a situation that has a tendency to remind us of a time we thought was forgotten, that of the first Radeon. Yet, the rushed launch of GeForce 8800 GT is characterized by a more than problematic availability of those cards, and it's going to remain tight until January. Henceforth, what is AMD able to offer in this price range for the end of the year?


Direct3D 10.1: Incompatible?
With its new range of GPUs, the Radeon HD 3000, AMD is the first to support the next version of Direct3D: Direct3D 10.1. But what does this new revision of Microsoft's API has in store for us?

Incompatible?
When the first pieces of information on Direct3D 10.1 first leaked this summer, some websites echoed a troubling rumor; this new version would be incompatible with the previous one! Immediately, angry reactions were expressed throughout the web. As a matter of fact, Microsoft was reaping what it sowed with the buzz generated around Direct 3D. Indeed, gamers had had to accept that this version wouldn't be compatible with the previous ones and that it would specifically be linked to Redmond's latest OS: Vista. Microsoft had nevertheless promised that it was inevitable in order to guaranty a new future-proof API. And yet, a couple of months later, here are talks about a revision that dared be, once more, incompatible. For many, enough was enough.



Instancing 10: the demo of the Direct3D 10 SDK
However, as is often the case on the web, it all came to nothing, as Direct3D 10.1 is fully compatible with its predecessor. But let's dig deeper into what we mean when we talk about compatible versions of an API. Up until the ninth version, the various DirectX iterations followed one another and kept descending compatibility; when you installed a new DirectX version, you could play all of your older games that used previous versions. Similarly, it was possible for a game to create a DirectX 9 interface, but only use it as a DirectX 8 interface. Among other things, this allowed developers to only have to maintain one piece of code to support two kinds of cards; setting aside advanced features support for cards that truly handled DirectX 9. To do this, programmers had access to a structure that gave a detailed list of the card's real abilities. Inversely, this compatibility no longer exists in Direct3D 10. To ensure older games ran on Vista, Microsoft integrated both APIs in its latest OS.



Windows Vista APIs
In a similar fashion, a Direct3D 10 interface doesn't grant access to the ninth version APIs, as many were deleted. If a developer wishes a game to support Direct3D 9 and 10, it's compelled to plan for two distinct version of a game, which isn't really different from what he had to do if he had wanted to support OpenGL and Direct3D. We talk of incompatible APIs in this particular case.

Inversely, it's quite possible to create a Direct3D 10.1 interface on a card that's only Direct3D 10, the new API being a strict superset of the latter. Everything found in Direct3D 10 is also found in its big brother. The developer's only duty is to ensure that he doesn't call features only present in Direct3D 10.1 on a Direct3D 10 card, which was already a necessity with previous versions of the API.

Obviously, the already available Direct3D 10 GPUs (G8x, G9x and R6x0) don't support the latest API's add-ons, which seems to be a no brainer and yet this point has generated a lot of confusion. Actually, in regards to older GPU support, Microsoft had promised the death of Caps bits with Direct3D 10 and has kept its word... well, sort of; from now on, Caps bits no longer exist, but have been replaced by what Microsoft calls Feature Level. The main difference is that it's no longer necessary to ensure that each feature is individually supported; one needs only check if the feature level is Direct3D 10 or Direct3D 10.1, which is enough to determine precisely what is supported by the GPU.

Direct3D 10.1: What's New
Let's be clear right from the start; the new things brought by this new API aren't revolutionary. Direct3D 10 was a big makeover and as always with such endeavors, there are small errors. Thus Direct3D 10.1 must be seen as an incremental update, correcting, thanks to time and distance, small holes in the previous API, and bringing a few add-ons in order to erase some of the restrictions that still existed.

All the improvements may be summed up in three categories:

Stricter specifications in order to limit discrepancies between multiple implementations
A handful of new features
A clear focus on rendering quality and more precisely, antialiasing
Stricter Specifications
Microsoft has taken advantage of Direct3D 10.1 to make its API even more orthogonal by cancelling particular situations; hence it is now compulsory to support FP32 textures' filtering, while it was only optional in Direct3D 10 (though all Direct3D 10 GPUs from both manufacturers were already supporting it anyway). In a similar fashion, blending in 16 bits integer buffers is now obligatory when its implementation was only a choice with Direct3D 10.

Microsoft has also strengthened specifications with regard to computational precision, whether in blending or in-shaders operations. Thus, many operations (addition, subtraction, multiplication and division) are now in line with the IEEE-754 norm, which, one must admit, isn't really exciting for gamers, but will surely please researchers fond of GPGPU.

New Features
Microsoft managed to be reasonable when it came to the new API add-ons. Developers are still assimilating the new features brought by Direct3D 10 and figuring what they can really do with them. It was, therefore, out of question to drown them every year under the flow of new add-ons.

First of all, we find Cube Map Arrays. With Direct3D 10, Microsoft had introduced Texture Arrays, tables of textures that could be indexed directly in the shaders. At first, Texture Arrays resemble 3D textures, which have been around for a long time, but practically, their behavior is very different. Ergo, when accessing an element of a 3D texture, a filtering occurs between the different layers, which is normal as a 3D texture is voluminal. On the contrary, textures stocked in a table may not have any connection between them. Consequently there isn't any filtering between neighboring elements. Furthermore, when using mipmapping, a 3D texture is divided by 2 according to its 3 dimensions, which isn't the case with Texture Arrays; if the different textures composing it see their size decreasing, the size of the table remains the same.

Direct3D 10.1 generalizes those Texture Arrays by adding support for Cube Maps tables whereas, until now, only 1D and 2D texture tables were supported.



CubeMap arrays
Shader Core wise, Direct3D 10.1 introduces Shader Model 4.1 which brings a couple of new things like the Gather-4, which is another name for Fetch-4 (introduced with ATI's previous generation of cards). To quickly refresh your memory, this instruction allows retrieving 4 unfiltered elements of a single-channel texture with just one texture fetch, which permits a more efficient implementation of personalized filters in shaders.



Fetch4
Another instruction added to Shader Model 4.1 enables it to recuperate the level of detail (mipmap level) during a texture sampling. Microsoft has also upgraded certain limits, especially the number of vertex shaders' input and output elements as we go from 16 vectors of 128-bit (4 floating simple precision) to 32.



D3D 10.1 Pipeline
With regard to blending, we've already mentioned the new supported format: Int. 16, but it's not the only new thing; Direct3D 10.1 now enables specification of independent blending modes during a simultaneous rendering in more than one buffer (MRT: Multiple Render Targets).

Aiming At Quality
With Direct3D 10.1, Microsoft has focused on rendering quality more than any of the other new features, so to speak. And the main focal point was antialiasing. First news: from now on, the support of antialiasing 4x is compulsory for 32-bit (RGBA8) as well as 64-bit (RGBA16) buffers. Furthermore, samples' position is also specified by the API and must be configurable. Without going as far as the ability to freely program samples' position, an application must at least be able to choose between many predefined patterns.

Beyond more strictly defined specifications, Microsoft has also sought to rationalize a little antialiasing management by offering much more control to programmers and by resorting less to the GPU manufacturers' homemade recipes. One has to admit that until now, users had access to a number of options quite disconcerting to beginners: apart from antialiasing levels (2x, 4x, 8x), the user had access to transparency antialiasing to filter alpha textures either in multisampling or supersampling mode, and on top of that were added specific features from each Independent Hardware Vendor (IHV): CSAA or CFAA... With Direct3D 10.1, programmers can finally specify if they want multisampling or supersampling by primitive and he also has access to the coverage mask of each pixel, which grants him control on samples on which shaders are applied.



D3D 10.1 Antialiasing
Finally, whereas Direct3D 10 enabled the access to samples of a multisampled color buffer, it's now possible to do the same thing in a multisampled depth buffer.

Practically, most of those features aren't new. Each manufacturer more or less included them in its own way and allowed their activation in its drivers. What's really new is that Direct3D 10.1 finally allows all this to be opened to games' programmers. Henceforth, driver's programmers will no longer be in charge of developing new antialiasing modes but games' programmers will now handle it according to the specific needs of their engines, a little like what is already happening on consoles where programmers have access to a lower hardware level.

Microsoft therefore gives the best there is to developers while waiting for totally programmable ROP, which would make all this even more flexible and clearer.

And Practically?
Practically, don't hope for much in the meantime. We are still waiting for developers to master Direct3D 10 and for them not to be limited by the Direct3D 9 versions of their engines that they still must upgrade, so there's little chance that they'll run towards Direct3D 10.1; the hardware is barely out and the API won't be available until Vista's Service Pack 1 in 2008.

Nevertheless, some features should allow for interesting effects. Specifically, Cube Map Arrays could simplify dynamic reflections, even if one must not forget the impact on other portions of the pipeline. Actually, in today's games, dynamic reflections are usually only applied to main elements (and the frequency of the reflections' update is far less important than the screen's refresh rate) in order to save some fill rate. If Cube Map Arrays take away a restriction on the number of simultaneous reflection, it doesn't cancel the others. We'll thus wait to really appreciate it in games, rather than in a handful of demos formatted by AMD or Microsoft.

Independent blending modes for each buffer when using MRT should ease the development of deferred shading rendering engines. Combined with possibilities to read antialiasing samples of color and depth buffers, those engines won't be forced to abandon antialiasing for a vague blur that is of questionable interest.

The other new features bring more additional comfort to developers than they truly do to gamers.