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

  • Agentbolt - Wednesday, September 23, 2009 - link

    Informative and well-written. My main question was "how future-proof is it?" I got the Radeon 9700 for DirectX9, the 8800GTS for DirectX10, and it looks like I may very well be picking this up for DirectX11. It's nice there's usually one card you can pick up early that'll run games for years to come at acceptable levels.
  • kumquatsrus - Wednesday, September 23, 2009 - link

    great article and great card btw. just wanted to point out that the gtx 285 also had 2x6 pins only required, i believe.
  • Ryan Smith - Wednesday, September 23, 2009 - link

    That's correct. I'm not sure how "275" ended up in there.
  • SiliconDoc - Wednesday, September 23, 2009 - link

    One wonders how the 8800GT ended up on the Temp/Heat comparison, until you READ the text, and it claims heat is "all over the place", then the very next line is "ALL the Ati's are up @~around 90C" .

    Yes, so temp is NOT alkl over the place, it's only VERY HIGH for ALL the ATI cards... and NVIDIA cards are not all very high...

    -so it becomes CLEAR the 8800GT was included ONLY so the article could whine it was at 92C, since the 275 is @ 75C and the 260 is low the 285 is low, etc., NVidia WINS HANDS DOWN the temperature game...... buit the article just couldn't bring itself to be HONEST about that.
    ---
    What a shame. Deception, the name of the game.
  • Ryan Smith - Wednesday, September 23, 2009 - link

    The 8800GT, as was the 3870, was included to offer a snapshot of an older value product in our comparisons. The 8800GT in particular was a very popular card, and there are still a lot of people out there using them. Including such cards provides a frame of reference for performance for people using such cards.
  • SiliconDoc - Wednesday, September 23, 2009 - link

    Gee I cannot imagine load temps for the 4980 and 4870x2 exist anywhere else on this site along with the 260,275, and 285... can you ?
    Oh, how about I look...
  • Finally - Wednesday, September 23, 2009 - link

    Nvidida-Trolls tend to turn green when feeling inferior.
  • SiliconDoc - Wednesday, September 23, 2009 - link

    Turning green was something the 40nm 5870 was supposed to do wasn't it ?
    Instead it turned into another 3D HEAT MONSTER, like all the ati cards.
    Take a look at the power charts, then look at that "wonderful tiny ATI die size that makes em so much money!" (as they lose a billion plus a year), and then calculate that power into that tiny core, NOT minusing failure for framerates hence "less data", since of course ati cards are "faster" right ?
    So you've got more power in a smaller footprint core...
    HENCE THE 90 DEGREE CELCIUS RUNNING RATES, AND BEYOND.
    ---
    Yeah, so sorry that it's easier for you to call names than think.
  • RubberJohnny - Wednesday, September 23, 2009 - link

    LOL...replying to your own post 3 times...gettin all worked up about temps...PUTTIN STUFF IN CAPS...

    Looks like this fan boy just can't accept that the 5890 is a great card. Not surprising really, these reviews always seem to bring the fanboys/trolls/whackos out of the woodwork.

    Once again, good job AT!!!
  • JarredWalton - Thursday, September 24, 2009 - link

    SiliconDoc, you should try thinking instead of trolling. Why would the maximum be around 90C? Because that's what the cards are designed to target under load. If they get hotter, the fan speeds would ramp up a bit more. There's no need to run fans at high rates to cool down hardware if the hardware functions properly.

    Reviewing based on max temperatures is a stupid idea when other factors come into play, which is why one page has power draws, temperatures, and noise levels. The GTX 295 has the same temperature not because it's "as hot" but because the fan kicked up to a faster speed to keep that level of heat.

    The only thing you can really conclude is that slower GPUs generate less heat and thus don't need to increase fan speeds. The 275 gets hotter than the 285 as well by 10C, but since the 285 is 11.3 dB louder I wouldn't call it better by any stretch. It's just "different".

Log in

Don't have an account? Sign up now