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
MrSpadge - Thursday, September 11, 2014 - link
The point is that Tonga is NOT a rebrand. It's a brand-new chip, AMD themselves call it the 3rd generation of GCN. Making a new chip costs AMD a sgnificant amount of money, that's why they haven't bothered yet to update Pitcairn to at least 2nd gen GCN (1.1). And I'm totally fine with that. It's also OK for nVidia to use GK104 for GTX760. What's not OK - from my point of view - is AMD investing into this new chip Tonga and hardly getting any real world benefit over the 3 year old Tahiti designs. If nVidia introduces a Maxwell which performs and costs them just the same as the previous Kepler, I'll call them out for this as well. But this is pretty much excluded, from what we've seen so far."And I highly doubt the 285 is 'all amd has'."
It's their 3rd gen GCN architecture, as they say themselves. There's going to be a bigger chip using this architecture, but apart from that I doubt we'll see anything from AMD in the next year which is not yet in Tonga.
just4U - Friday, September 12, 2014 - link
The one nice thing about the 285 is it will have resale value that has been lost on the 280-290 series thanks in large part to bit mining. There's a good chance that most won't feel that the 285 (and future incarnations) were run into the ground like the earlier ones were.Frenetic Pony - Wednesday, September 10, 2014 - link
Nah, what's interesting is that Maxwell may not be worth "responding" too. It's an almost totally mobile focused design, one that's not even totally out yet. If these benchmarks hold true then it's very exciting for AMD's upcoming high end. Nvidia may end up with a 512bit bus as well, but AMD's bandwidth optimizations will mean a similarly specced card of their's will still handily beat anything NVIDIA has in terms of resolution scaling.Heck it may even be enough to get a single GPU capable of running games at 4k at a reasonable fps. And that would be awesome. Maxwell might be good for Nvidia's mobile business, but I doubt it's going to help them take back the top spot for high end stuff from AMD.
mindbomb - Wednesday, September 10, 2014 - link
UVD always supported vc-1. The first version supported full decode of h264 and vc-1. You are thinking of nvidia, who didn't have full hardware decode on a real desktop part until fermi.mindbomb - Wednesday, September 10, 2014 - link
Not that it matters really. It stopped being relevant when hd-dvd lost to bluray.Navvie - Thursday, September 11, 2014 - link
A lot of blu-rays have vc-1 content.nathanddrews - Thursday, September 11, 2014 - link
Blu-ray.com has a database that you can search by codec. VC-1 is very much alive and thriving.Ryan Smith - Wednesday, September 10, 2014 - link
According to my DXVA logs, the 280 did not support VC-1/WMV9. That is what I'm basing that on.mindbomb - Wednesday, September 10, 2014 - link
I think your logs are referring to the nvidia gtx 280, which did not support full vc-1 decode. AMD had it since the radeon 2600xt, which is ancient.NikosD - Saturday, September 13, 2014 - link
True.One of the main advantages of first generation UVD (ATI Radeon HD2000 series) over Nvidia, was the full DXVA VLD support of both 1080p H.264 L4.1 (BluRay spec) and VC-1.