Related articles

• Source: AMD Utilizing a tessellator in the pipeline accelerated the performance of games, which had access and were coded for it. This is the case for games built for the Xbox 360. Not only models can be morphed but entire environments. During the Ruby demo, the development team showed just how easy it was to generate an entire scene by using procedurally generated maps. From this map of noise... ...to this final image using procedurally generated content in hardware. The team started by showing how a height map could be generated by either using Perlin noise or another technique. They were able to generate a low-poly wire frame mesh of the terrain and a normal map from the same height map. From here the snow was added to the mountains using a shader. There was no need for an artist to touch up the entire scene, which would have taken countless hours. Once all of the code was written, the entire scene came alive and was dynamically controlled by a set of sliders for tessellation and the snowfall.   Low Resolution with Tessellation High Resolution, No Tessellation On-disk model polygon count (pre-tessellation) 840 triangles 1,280,038 triangles Original model rendering cost 1210 fps (0.83 ms) Actual rendered model polygon count 1,008,038 triangles 1,280,038 triangles VRAM Vertex buffer size 70 kB 31 MB VRAM Index buffer size 23 kB 14 MB Rendering Time 821.41 fps (1.22 ms) 301 fps (3.32 ms) The memory footprint savings alone make it worth using tessellation. Then add in the cost savings for a studio measured by how much time it would take for an artist to create everything versus doing it procedurally. But here's the deal. While tessellation is a great feature, can you really expect that titles will come to market soon, which can use it? Let me put it this way, on the slide before the block diagram shown below, Boyd stated that a fixed function tessellator is already in the proposal and could even get its own stage in the pipeline. Click for a larger image. Source: Chas Boyd "The Future of DirectX", GDC 2007 Xbox 360 already has these titles. Many tools like Softimage exist on the market that can port DX9 over to DX10. Future releases of DX10 will include tessellation. In what exact format will tessellation come? So far it looks similar to what we see in R600. Of course, the change to tessellation will not happen overnight but the question isn't a matter of "if" but "when." ATI was smart to include such a piece of dedicated hardware.

• I still remember when ATI launched the original Radeon in 2000. Brian Hentschel called me up to ask for my opinion on the chip’s name, and I remember thinking Radeon was horrible. Shows you how well I’d do in PR. That architecture emphasized the gaming experience, with two pixel pipelines and three texture units per pipeline. Though the Radeon had a fairly high texel rate, pixel fill rate was what won the day back then, and the decision to “go pretty” ceded the performance battle to Nvidia. nVidia GeForce GTX 285... Dell Home $499.99 Newegg.com $394.99 Amazon.com $404.59 With R300 in 2002, ATI went the other way, putting its money behind eight pixel pipelines, each with a single texture unit—the focus was on performance—and the bet paid off. ATI smoked the GeForce4 Ti 4600 and fared well enough against an embarrassingly-loud GeForce FX 5800 Ultra. Performance or experience—which is better? With the Radeon HD 5870, ATI says it’s gunning for both. We’ve already covered the architecture, ATI’s key to delivering performance with Cypress. Now let’s take a closer look at the experience. ATI is relying on three components enabled through hardware here: its Eyefinity technology, Stream, and DirectX 11. Right off the bat, I think it’s fairly safe to say that for all of the hoopla ATI made about its DirectX 10.1 support, real gamers in the real world never saw a tangible benefit. I’ve played S.T.A.L.K.E.R.; I’ve played H.A.W.X. The experience on a DirectX 10 card versus DirectX 10.1 is not worth mention. And for that matter, I’d also argue that DirectX 10 hasn’t had as profound on impact on gaming experience as prior versions of the API. Why should we believe DirectX 11 is going to be any more prolific than its predecessor? The reality of the situation is that DirectX 11 probably won’t be as impactful as DirectX 8 or 9, both of which introduced key shading capabilities. But it is seen as the next logical step for ISVs still working with DirectX 9, since it’s a super-set of DirectX 10/10.1 supporting existing hardware, plus DX11 cards. Microsoft has made sure it's easier to code with DX11, so we really are expecting to see a faster up-take of the API than DirectX 10. New Features The notable features supported by DX11 are illustrated in the chart below. FeatureDirectX 10DirectX 10.1DirectX 11Tessellation--xShader Model--xDirectCompute 11--xDirectCompute 10.1-xxDirectCompute 10xxxMulti-ThreadingxxxBC6/BC7 Texture Compression--x ATI has included tessellation support in its GPUs since 2001. And while I’m not sure how much play those early hardware implementations actually got in the game development world, they’ve helped pave the way for tessellation as it exists today, exposed through a number of different implementations (Catmull-Clark subdivision surface modeling, Bézier patch meshes, n-patches, displacement mapping, and adaptive/continuous tessellation). Of course, the benefits of tessellation are apparent—more polygons mean more detail and hence more realism. And because tessellation is now standardized as a component of DirectX 11, ISVs are more likely to lean on it without the frustration of only supporting one vendor’s hardware. In fact, we saw Rebellion demonstrate tessellation in its upcoming Aliens Vs. Predator title, launching in Q1 of next year. DirectX 11 also introduces Shader Model 5.0, which offers developers a more object-oriented approach to coding HLSL. Ideally, this will help motivate ISVs to adopt the new API quicker, since programming becomes cleaner and more efficient (for a more specific example of this in practice, check out Fedy’s DirectX 11 preview). Gamers with multi-core processors should realize performance gains from DirectX 11-based titles by virtue of threading optimizations made to the API. ATI and Nvidia have been shipping multi-threaded drivers for three years now capable of dispatching commands to the GPU in parallel. According to Nvidia, this was worth anywhere from 10 to 40 percent additional performance back in ’06. But DirectX 11 goes even further, allowing the application, DirectX runtime, and driver to run in separate threads. ATI gives the example of loading textures or compiling shaders in parallel with the main rendering thread. In essence, the threading is much more granular, which, almost ironically, should prove more beneficial to AMD and Intel than ATI and Nvidia. Wait. Yeah. That’s a real win for AMD, isn’t it? Improved texture compression is another one of those developer-oriented enhancements that will benefit gamers through greater rendering quality without the expected corresponding performance hit to memory bandwidth. DirectX 11 includes two new block compression formats: BC6 and BC7. BC6 enables up to 6:1 compression of 16-bit high dynamic range textures with hardware decompression support. BC7 delivers up to 3:1 compression of eight-bit textures and normal maps.

• Achieving this generation’s five design goals required notable tweaks to ATI’s architecture, though many of the cues are clearly taken from the Radeon HD 4800-series (and indeed the 3800-series before that). Before we even get to the GPU’s shader processing capabilities, we have to take a look at the graphics engine, which includes ATI’s sixth-generation tessellation engine. We’ve seen the company evangelize tessellation in the past. But as with most things that only apply to one competitor, realization of this feature via actual games was limited. Now it’s part of the DirectX 11 pipeline, sandwiched on either side by the hull and domain shaders. The tessellator is a fixed-function component which can either be utilized or not, depending on the tessellation technique in play. In its architectural description, AMD ambiguously claims to include dual rasterizers. As you probably know, current GPUs are capable of rasterizing a single triangle per cycle, and that very serial approach has become the main reason for the performance bottlenecks that show up in synthetic geometry tests on unified-shader architectures. At first, we thought AMD had found a way to parallelize the setup, which would have been particularly well-suited to a GPU that places a lot of importance on tessellation. There are any number of options for rasterizing several triangles in parallel, but they’re very complex. So, we were curious to see how AMD had solved this puzzle. Unfortunately the answer was disappointing: AMD was playing fast and loose with its wording. In practice, there’s still only a single rasterizer, handling a single triangle per cycle. But now there are twice as many scan conversion units, generating 32 pixels per cycle in order to match the increase in ROPs. Instead of dual rasterizers, it would be better to simply call this implementation a more powerful rasterizer. While we’re on the subject of setup and rasterization, we should point out one other change. The fixed-function units that handled interpolation calculations have disappeared, and that job is now addressed by the shader processing units. AMD claims that the impact on performance is negligible, and this is in line with the current trend towards getting rid of as many fixed units as possible and taking advantage of the enormous processing power of modern GPUs. As mentioned on the previous page, the organization of ATI’s stream cores hasn’t changed. They have learned to operate more efficiently, though. We established in our first look at the Radeon HD 4850 that ATI’s VLIW architecture depends on an efficient compiler in order to maximize performance—otherwise those ALUs idle. With RV770, each of the five instructions in a VLIW bundle had to be independent of the others. Now, Cypress is able to execute a multiplication and addition dependent on the outcome of the previous operation in the same cycle. Take the following example: a=b*c; d=a+x; These wouldn’t have been able to share the same instruction bundle on the RV770. But here they can, since these two operations are turned into one MAD, while conserving the result of the intermediate multiplication operation. Similarly, the RV770 only had a DP4 (four-component scalar product) instruction, with the DP2 and DP3 instructions implemented using DP4. The result of that design was certain slots of the bundle were wasted on unnecessary operations. AMD says that handling of scalar products is now more flexible, though they haven't elaborated further. We suppose that the engineers have implemented DP2 and DP3 instructions natively to allow execution of other calculations in parallel. Handling of integer operations has also been changed. Before, each of the four stream cores could execute one addition or bit shift operation on a 32-bit integer per cycle, and the special-function core could perform a multiplication or a bit shift (also on a 32-bit integer). Now the four cores are capable of performing a multiplication or addition per cycle, but only on 24-bit integers. This choice is the result of a compromise between increasing overall performance and not sacrificing too many resources to do it, as having a complete 32-bit integer multiplier in each of the stream cores would have done. By limiting themselves to 24-bit operations, the engineers can re-use resources used for handling single-precision floating-point numbers, while still maximizing utilization of the shader. In addition to these optimizations, ATI's design team has introduced two new instructions: a fused multiply-add instruction (FMAD) which maintains the precision of the calculation throughout and performs a single final rounding, unlike a standard multiply-add (MAD), which performs two roundings. The second instruction is a sum of absolute differences (SAD), an operation frequently used in video (in particular for comparing blocks of pixels). We verified these increases in processing power using different shaders. Though we’ve maintained a 2.26x gain between the Radeon HD 4870 and HD 5870 for most of the simple DirectX 9 shaders we launched, it was reduced to 1.68x when we added per-pixel lighting. Now let’s move to more complex DirectX 10 shaders: With procedural textures, the theoretical gain in raw power is almost completely realized, as the Radeon HD 5870 is 2.24x faster than the 4870. There’s no doubt that the 1,600 stream processors are present and accounted for here. If the stream processing units haven’t changed fundamentally, the texture units have barely changed at all compared to the RV770. In practice, except for support for 16Kx16K textures and two new texture compression formats (both of which were necessary for DirectX 11 compatibility), there’s nothing new. Steep Parallax Mapping shows that fairly clearly: The drivers also seem to have added slight optimization, because the gain we measured here (but also with other shaders, like Fur) is as high as 2.35x between the two Radeons. Performance with geometry shaders (geometry power), on the other hand, has improved by only 42%. This last test measures texture fetching performance (important for displacement mapping, for example). It shows a modest improvement of 34%. You should keep in mind that while the total bandwidth of the L1 cache has increased, it’s only by a factor of two, which is commensurate with the increase in the number of texture units. In the same way, the size of the L2 cache has doubled. But again, that's only because the number of units has also doubled. Worse, the L1/L2 bandwidth has increased only in proportion to the GPU's frequency, whereas there are now twice as many units to supply. We may have just put our finger on one reason why Cypress failed to show two times the performance of its predecessor in the preceding texture tests. There’s not much new where the ROPs are concerned, either. AMD has simply optimized the links between the ROPs and the texture units, allowing the texture units to read the compressed format used when anti-aliasing is enabled. This feature, which Nvidia GPUs already have, should result in better performance during frame buffer post-processing operations. Aside from that, the characteristics are exactly the same as on the RV770; maximum output with 2x and 4x (32 pixels/cycle) anti-aliasing, but reduced by half (16 pixels /cycle) when 8x antialiasing is used. There’s also been no optimization of Z-only render passes, which are still done four times as fast (128 pixels/cycle).