Memory Interface, UVD2.2

Physically, the memory controllers have been tweaked in order to increase area efficiency/density, and we're told this was one of the main reasons for the rather impressive density increase Cypress brought. Furthermore, they now “service” two RBEs, as opposed to just one in the RV770, which may translate into more efficient bandwidth usage.

In an effort to satisfy the more stringent requirements with regards to memory transfer correctness specific to the GPU compute segment, support for what ATI dubs Error Detection Code has been included. In practice, this adds Cyclic Redundancy Checking to memory transfers. CRC uses polynomial codes, dividing the data sequence to be transmitted by a polynomial, appending the remainder (CRC digits) to the data sequence to be transmitted. In order to check validity, after a data transfer the MC again divides the data sequence itself by the polynomial, checking for equality between the resulting remainder and the one passed as CRC digits. In the case of equality, there's no detectable error, but this is not a catch-all solution and choosing the right polynomial to divide by is important in ensuring maximum coverage of potential errors.

A perk of this approach is that the division process itself, which uses modulo-2 arithmetic, discarding carries and borrows, can be equivalently expressed  with just XORing, which should be pretty fast. We don't know what polynomial ATI has chosen to use, but it should be of a fairly high degree if they want to catch most errors, given that Cypress can burst up to 256-bits. Error correction is probably no more than asking for a re-transmission of the offending data sequence.

The final significant change is represented by the ability to “hide” the effects of GDDR5's link retraining protocol. The problem was that whilst automatically adjusting timing parameters is nice, it's not an instantaneous process, and had annoying visual effects like screen flashes – which brought about the rather unfortunate solution of not changing RAM clocks so that the re-training sequence never had to occur in normal usage. This is no longer the case for Cypress, thankfully.

And this is where novelties stop, and where the head-scratching part begins: Cypress is twice the chip that an RV790 is, but has only ~23% extra bandwidth compared to that – this seems a bit on the low side, to say the least. We can see the technical reasons for not widening the memory interface, as that would've implied rather serious transistor and wiring costs, and the budget for both was probably becoming rather tight. However, we can't help but wonder if this won't end up being a limiting factor in many scenarios, and it will be interesting to see how things went.

The display output pipe for Cypress, and the Evergreen family in general, is something you'll probably hear a lot about in conjunction with, or rather under the umbrella of, Eyefinity, its marketing moniker. In practice, the display output can drive up to two dual-link DVI connections or two HDMI and up to 6 DisplayPort ones with up to 10 bit per colour component precision. There are also dual 400MHz DACs on-board for those still caught in analog hell. There are only 2 clock-sources dedicated to Display, present to drive DVI and HDMI, so then any output count higher than two leverages the fact that DP doesn't actually need a clock source. The bumping of HDMI to version 1.3a means that you're likely to always see a dedicated HDMI output on SKUs exposing it, rather than an DVI-to-HDMI adapter.

With current cards you can drive up to 3 displays with a single board, using either 2 DVIs and 1 DP, or 1 DVI, 1 HDMI and 1 DP, or 1 DVI , 1 Analog VGA (why???) and 1 DP, or 3 DP, although you'll need two DVI-to-DP adapters for that.  Take a deep breath.  Later this year, a 6 DP edition will be out, for those dreaming about walls of pixels. We presume this'll be a rather big hit with entities that care about visualization a lot, and chip away at the market Matrox had carved for itself via it's multi-display tech. We'll tell you more about Eyefinity/the multi-display capabilities of Evergreens at a later date, once we've had some hands-on experience with it.

To finalize things, we should discuss UVD2.2, or rather what's up with the .2 part. Cypress implements a slightly updated video processing engine, that had already been included in the RV710/RV730/RV740. The memory interface has been reworked, and it's marginally better at handling HD streams. Other than that, there are no changes, so you get full H264/VC-1/MPEG-2 decode assistance, post-processing as well as dual video stream support (PiP). And with that incredibly informative nugget we're done with this first iteration of our theoretical analysis of Cypress' architecture. We're going to be showing you some testing results now, and wrap things up for this round.