AMD Radeon R9 285 Review: Feat. Sapphire R9 285 Dual-X OC
by Ryan Smith on September 10, 2014 2:00 PM ESTSynthetics
As always we’ll also take a quick look at synthetic performance. As we briefly discussed in our look at the GCN 1.2 architecture these tests mainly serve as a canary for finding important architectural changes, and one of these tests in particular has been significantly impacted by AMD’s newest round of architectural improvements.
At the x64 tessellation factor we see the R9 285 spit out 134fps, or equivalent to roughly 1.47B polygons/second. This is as compared to 79fps (869M Polys/sec) for the R9 290, and 68fps (748M Polys/sec) for the R9 280. One of the things we noted when initially reviewing the R9 290 series was that AMD’s tessellation performance didn’t pick up much in our standard tessellation benchmark (Tessmark at x64) despite the doubling of geometry processors, and it looks like AMD has finally resolved that with GCN 1.2’s efficiency improvements. As this is a test with a ton of small triangles, it looks like we’ve hit a great case for the vertex reuse optimizations.
Moving on, we have our 3DMark Vantage texture and pixel fillrate tests, which present our cards with massive amounts of texturing and color blending work. These aren’t results we suggest comparing across different vendors, but they’re good for tracking improvements and changes within a single product family.
With AMD maintaining their same texture units and same tex:FP32 ratio for Tonga, the end result is that R9 285’s texturing performance is virtually identical to R9 280’s. Ignoring any possibility of caching or bandwidth bottlenecking for the moment, R9 285 can push texels just as well as R9 280 could.
Unlike our texel test, AMD’s delta color compression technology introduced on GCN 1.2 has an incredible impact on R9 285’s pixel throughput. This pixel test is normally memory bandwidth bound, providing something that approaches a best case scenario for AMD’s compression technology. As a result despite possessing nearly 30% less memory bandwidth than the R9 280, the R9 285 tops our charts at 19.9 GPix/sec, blowing past the R9 280 by 68%. Even the R9 290 with its 512-bit memory bus and doubled ROP count still falls short here by over 3GPix/sec, or 16%.
This benchmark in a nutshell is why AMD can deliver the average performance of the Tahiti based R9 280 without Tahiti’s memory bandwidth. By improving their color compression to this point AMD can significantly reduce their memory bandwidth requirements on GCN 1.2, allowing them to do more with less. In real games the result won’t be anywhere near this remarkable since this is a pure pixel fillrate test, but it goes to show that AMD has been able to neutralize their memory bandwidth deficit in graphics workloads.
Facebook
Twitter
RSS
86 Comments
View All Comments
Alexvrb - Tuesday, September 16, 2014 - link
"if other GCN 1.1 parts like Hawaii are any indication, it's much more likely the 280 maintains its boost clocks compared to the 285 (due to low TDP limits)"This is what you said. This is where I disagreed with you. The 285 maintains boost just as well as the 280. Further, GCN 1.1 Bonaire and even Hawaii reach and hold boost at stock TDP. The 290 series were not cooled sufficiently using reference coolers, but without any changes to TDP settings (I repeat, stock TDP) they boost fine as long as you cool them. GCN 1.1 boosts fine, end of story.
As far as Tonga goes, there's almost no progress in performance terms. In terms of power it depends on the OEM and I've seen good and bad. The only additions that really are interesting are the increased tessellation performance (though not terribly important at the moment) and finally getting TrueAudio into a mid-range part (it should be across the board by next gen I would hope - PS4 and XB1 have the same Tensilica DSPs).
I would hope they do substantially better with their future releases, or at least release a competent reference design that shows off power efficiency better than some of these third party designs.
chizow - Wednesday, September 17, 2014 - link
Yes, and my comment was correct, it will ALWAYS be "more likely" the 280 maintains its boost over other GCN 1.x parts because we know the track record of GCN 1.0 cards and their conservative Boost compared to post-PowerTune GCN1.x and later parts as a result of the black eye caused by Hawaii. There will always be a doubt due to AMD's less-than-honest approach to Boost with Hawaii, plain and simple.I also (correctly) qualified my statement by saying the low stated TDP of the 285 would be a hindrance to exceeding those rated specs and/or the performance of the 280, and we also see that is the case that in order to exceed those speed limits, AMD traded performance for efficiency to the point the 285's power consumption is actually closer to the 250W rated 280.
In any case, in another day or two, this unremarkable part is going to become irrelevant with GM104 Maxwell, no need to further waste any thoughts on it.
etherlore - Thursday, September 11, 2014 - link
Speculating here. The data parallel instructions could be a way to share data between SIMD lanes. I could see this functionality being similar in functionality to what threadgroup local store allows, but without explicit usage of the local store.It's possible this is an extension to, or makes new use of, the 32 LDS integer units in GCN. (section 2.3.2 in the souther islands instruction set docs)
vred - Thursday, September 11, 2014 - link
And... DP rate at last. Sucks to have it at 1/16 but at least now it's confirmed. First review where I see this data published.chizow - Thursday, September 11, 2014 - link
It has to be artificially imposed, as AMD has already announced FirePro cards based on the Tonga ASIC that do not suffer from this castrated DP rate. AMD as usual taking a page from Nvidia's playbook, so now all the AMD fans poo-poo'ing Nvidia's sound business decisions can give AMD equal treatment. Somehow I doubt that will happen though!Samus - Thursday, September 11, 2014 - link
If this is AMD's Radeon refresh, if the 750Ti tells us anything, they are screwed when Maxwell hits the streets next month.Atari2600 - Thursday, September 11, 2014 - link
The one thing missed in all this - APUs.As we all know, APUs are bandwidth starved. A 30-40% increase in memory subsystem efficiency will do very nicely for removing a major bottleneck.
That is before the move to stacked chips or eDRAM.
limitedaccess - Thursday, September 11, 2014 - link
@RyanRegarding the compression (delta color compression) changes for Tonga does this have any effect on the actual size of data stored in VRAM.
For instance if you take a 2gb Pitcarin card and a 2gb Tonga card showing the identical scene in a game will they both have identical (monitored) VRAM usage? Assuming of course the scenario here is neither is actually hitting the 2gb VRAM limit.
I'm wondering if it possible to test whether or not this is the case if unconfirmed.
Ryan Smith - Sunday, September 14, 2014 - link
VRAM usage will differ. Anything color compressed will take up less space (at whatever ratio the color compression algorithm allows). Of course this doesn't account for caching and programs generally taking up as much VRAM as they can, so it doesn't necessarily follow that overall VRAM usage will be lower on Tonga than Pitcairn. But it is something that can at least be tested.abundantcores - Thursday, September 11, 2014 - link
I see Anand still don't understand the purpose of Mantle, if they did they wouldn't be using the most powerful CPU they could find, i would explain it to them but i think its already been explained to them a thousand times and they still don't grasp it.Anand are a joke, they have no understanding of anything.