Cypress: What’s New

With our refresher out of the way, let’s discuss what’s new in Cypress.

Starting at the SPU level, AMD has added a number of new hardware instructions to the SPUs and sped up the execution of other instruction, both in order to improve performance and to meet the requirements of various APIs. Among these changes are that some dot products have been reduced to single-cycle computation when they were previously multi-cycle affairs. DirectX 11 required operations such as bit count, insert, and extract have also been added. Furthermore denormal numbers have received some much-needed attention, and can now be handled at full speed.


Perhaps the most interesting instruction added however is an instruction for Sum of Absolute Differences (SAD). SAD is an instruction of great importance in video encoding and computer vision due to its use in motion estimation, and on the RV770 the lack of a native instruction requires emulating it in no less than 12 instructions. By adding a native SAD instruction, the time to compute a SAD has been reduced to a single clock cycle, and AMD believes that it will result in a significant (>2x) speedup in video encoding.

The clincher however is that SAD not an instruction that’s part of either DirectX 11 or OpenCL, meaning DirectX programs can’t call for it, and from the perspective of OpenCL it’s an extension. However these APIs leave the hardware open to do what it wants to, so AMD’s compiler can still use the instruction, it just has to know where to use it. By identifying the aforementioned long version of a SAD in code it’s fed, the compiler can replace that code with the native SAD, offering the native SAD speedup to any program in spite of the fact that it can’t directly call the SAD. Cool, isn’t it?

Last, here is a breakdown of what a single Cypress SP can do in a single clock cycle:

  • 4 32-bit FP MAD per clock
  • 2 64-bit FP MUL or ADD per clock
  • 1 64-bit FP MAD per clock
  • 4 24-bit Int MUL or ADD per clock
  • SFU : 1 32-bit FP MAD per clock

Moving up the hierarchy, the next thing we have is the SIMD. Beyond the improvements in the SPs, the L1 texture cache located here has seen an improvement in speed. It’s now capable of fetching texture data at a blistering 1TB/sec. The actual size of the L1 texture cache has stayed at 16KB. Meanwhile a separate L1 cache has been added to the SIMDs for computational work, this one measuring 8KB. Also improving the computational performance of the SIMDs is the doubling of the local data share attached to each SIMD, which is now 32KB.


At a high level, the RV770 and Cypress SIMDs look very similar

The texture units located here have also been reworked. The first of these changes are that they can now read compressed AA color buffers, to better make use of the bandwidth they have. The second change to the texture units is to improve their interpolation speed by not doing interpolation. Interpolation has been moved to the SPs (this is part of DX11’s new Pull Model) which is much faster than having the texture unit do the job. The result is that a texture unit Cypress has a greater effective fillrate than one under RV770, and this will show up under synthetic tests in particular where the load-it and forget-it nature of the tests left RV770 interpolation bound. AMD’s specifications call for 68 billion bilinear filtered texels per second, a product of the improved texture units and the improved bandwidth to them.

Finally, if we move up another level, here is where we see the cause of the majority of Cypress’s performance advantage over RV770. AMD has doubled the number of SIMDs, moving from 10 to 20. This means twice the number of SPs and twice the number of texture units; in fact just about every statistic that has doubled between RV770 and Cypress is a result of doubling the SIMDs. It’s simple in concept, but as the SIMDs contain the most important units, it’s quite effective in boosting performance.


However with twice as many SIMDs, there comes a need to feed these additional SIMDs, and to do something with their products. To achieve this, the 4 L2 caches have been doubled from 64KB to 128KB. These large L2 caches can now feed data to L1 caches at 435GB/sec, up from 384GB/sec in RV770. Along with this the global data share has been quadrupled to 64KB.


RV770 vs...


Cypress

Next up, the ROPs have been doubled in order to meet the needs of processing data from all of those SIMDs. This brings Cypress to 32 ROPs. The ROPs themselves have also been slightly enhanced to improve their performance; they can now perform fast color clears, as it turns out some games were doing this hundreds of times between frames. They are also responsible for handling some aspects of AMD’s re-introduced Supersampling Anti-Aliasing mode, which we will get to later.

 

Last, but certainly not least, we have the changes to what AMD calls the “graphics engine”, primarily to bring it into compliance with DX11. RV770’s greatly underutilized tessellator has been upgraded to full DX11 compliance, giving it Hull Shader and Domain Shader capabilities, along with using a newer algorithm to reduce tessellation artifacts. A second rasterizer has also been added, ostensibly to feed the beast that is the 20 SIMDs.

A Quick Refresher on the RV770 DirectX11 Redux
Comments Locked

327 Comments

View All Comments

  • Xajel - Wednesday, September 23, 2009 - link

    Ryan,

    I've send a detailed solution for this problem to you ( Aero disabled when running and video with UVD accerelation ), but the basic for all readers here is just install HydraVision & Avivo Video Convertor packages, and this should fix the problem...
  • Ryan Smith - Wednesday, September 23, 2009 - link

    Just so we're clear, Basic mode is only being triggered when HDCP is being used to protect the content. It is not being triggered by just using the UVD with regular/unprotected content.
  • biigfoot - Wednesday, September 23, 2009 - link

    Well, I've been looking forward to reading your review of this new card for a little while now, especially since the realistic sounding specs leaked out a week or so ago. My first honest impression is that it looks like it'll be a little bit longer till the drivers mature and the game developers figure out some creative ways to bring the processor up to its full potential, but in the mean time, it looks like I'd have to agree with everyone's conclusion that even 150+GB/s isn't enough memory bandwidth for the beast, I'm sure it was a calculated compromise while the design was still on the drawing board. Unfortunately, increasing the bus isn't as easy as stapling on a couple more memory controllers, they probably would've had to resort back to a wider ring bus and they've already been down that road. (R600 anyone) Already knowing how much more die area and power would've been required to execute such a design probably made the decision rather easy to stick with the tested 4 channel GDDR5 setup that worked so well for the RV770 and RV790. As for how much a 6 or 8 channel (384/512 bit) memory controller setup would've improved performance, we'll probably never know; as awesome as it would be, I don't foresee BoFox's idea of ATI pulling a fast one on nVidia and the rest of us by releasing a 512-bit derivative in short order, but crazier things have happened.
  • biigfoot - Wednesday, September 23, 2009 - link

    Oh, I also noticed, they must of known that the new memory controller topology wasn't going to cut it all the time judging from all the cache augmentations performed. But like i said, given time, I'm sure they'll optimize the drivers to take advantage of all the new functionality, I'm betting that 90% of the low level functions are still handled identically as they were in the last generations architecture and it will take a while till all the hardware optimizations like the cache upgrades are fully realized.
  • piroroadkill - Wednesday, September 23, 2009 - link

    The single most disappointing thing about this card is the noise and heat.

    Sapphire have been coming out with some great coolers recently, in their VAPOR-X line. Why doesn't ATI stop using the same dustbuster cooler in a new shiny cover, and create a much, much quieter cooler, so the rest of us don't have to wait for a million OEM variations until there's one with a good cooler (or fuck about and swap the cooler ourselves, but unless you have one that covers the GPU AND the RAM chips, forget it. Those pathetic little sticky pad RAM sinks suck total donkey balls.)
  • Kaleid - Wednesday, September 23, 2009 - link

    Already showing up...

    http://www.techpowerup.com/104447/Sapphire_HD_5870...">http://www.techpowerup.com/104447/Sapphire_HD_5870...

    It will be possible to cool the card quietly...
  • Dante80 - Wednesday, September 23, 2009 - link

    the answer you are looking for is simple. Another, more elaborate cooler would raise prices more, and vendors don't like that. Remember what happened to the more expensive stock cooler for the 4770? ...;)
  • Cookie Monster - Wednesday, September 23, 2009 - link

    When running dual/multi monitors with past generation cards, the cards would always run at full 3d clocks or else face instabilities, screen corruptions etc. So even if the cards are at idle, it would never ramp down to the 2d clocks to save power, rending impressive low idle power consumption numbers useless (especially on the GTX200 series cards).

    Now with RV870 has this problem been fixed?
  • Ryan Smith - Wednesday, September 23, 2009 - link

    That's a good question, and something we didn't test. Unfortunately we're at IDF right now, so it's not something we can test at this moment, either.
  • Cookie Monster - Wednesday, September 23, 2009 - link

    It would be awesome if you guys do get some free time to test it out. Would be really appreciated! :)

Log in

Don't have an account? Sign up now