Compute

Jumping into compute, our expectations regarding compute performance are going to be a mixed bag. On the one hand as part of the newer GCN 1.2 architecture AMD has been doing some tweaking under the hood, but on the other hand the most important aspects of the architecture – the memory model and thread execution – are not fundamentally different from the GCN 1.0 R9 280. As a result we’re not necessarily expecting to find any performance leaps here but there is the possibility that we will find some along the way.

As always we’ll start with LuxMark2.0, the official benchmark of SmallLuxGPU 2.0. SmallLuxGPU is an OpenCL accelerated ray tracer that is part of the larger LuxRender suite. Ray tracing has become a stronghold for GPUs in recent years as ray tracing maps well to GPU pipelines, allowing artists to render scenes much more quickly than with CPUs alone.

Compute: LuxMark 2.0

Right off the bat we find an unexpected regression in performance with LuxMark. All things considered we would expect the R9 285 to score similarly to the R9 280 given their nearly identical theoretical FP32 throughput, similar to what we’ve seen in our gaming benchmarks. Instead we have the R9 285 trailing its predecessor by 15%, and coming very close to tying the otherwise much slower R9 270X. Given that this is a new architecture there are a few possibilities here including a lack of OpenCL driver optimizations on AMD’s part, though we can’t entirely rule out bandwidth either since ray tracing can burn up bandwidth at times. Tonga is after all first and foremost a graphics product, and AMD’s memory bandwidth saving compression technology is similarly designed for graphics and not compute, meaning the R9 285 doesn’t have much to make up for the loss of bandwidth in compute tasks versus the R9 280.

In any case, even with R9 285 lagging the R9 280, it’s otherwise a strong showing for AMD. AMD cards overall perform very well on this benchmark compared to NVIDIA’s offerings, so the R9 285 has no trouble shooting well past the GTX 760.

Our 2nd compute benchmark is Sony Vegas Pro 12, an OpenGL and OpenCL video editing and authoring package. Vegas can use GPUs in a few different ways, the primary uses being to accelerate the video effects and compositing process itself, and in the video encoding step. With video encoding being increasingly offloaded to dedicated DSPs these days we’re focusing on the editing and compositing process, rendering to a low CPU overhead format (XDCAM EX). This specific test comes from Sony, and measures how long it takes to render a video.

Compute: Sony Vegas Pro 12 Video Render

Unlike LuxMark, we aren’t seeing a performance gain nor a regression here. The R9 285 is every bit as fast as the R9 280. Meanwhile as has consistently been the case in this benchmark, all of AMD’s cards are well ahead of our NVIDIA cards.

Our 3rd benchmark set comes from CLBenchmark 1.1. CLBenchmark contains a number of subtests; for our standard benchmark suite we focus on the most practical of them, the computer vision test and the fluid simulation test. The former is a useful proxy for computer imaging tasks where systems are required to parse images and identify features (e.g. humans), while fluid simulations are common in professional graphics work and games alike.

Compute: CLBenchmark 1.1 Fluid Simulation

Compute: CLBenchmark 1.1 Computer Vision

Depending on which subtest we’re looking at, the R9 285 either outperforms or trails the R9 280. The fluid simulation subtest finds the R9 285 performing just shy of the more powerful R9 280X, while the R9 285 comes up short of the R9 280 in computer vision. Computer vision is the more bandwidth sensitive benchmark of the two, so it follows that it’s the benchmark more likely to be influenced by the loss of raw memory bandwidth. Otherwise the R9 285’s strong showing in the fluid simulation is unexpected, and given what we know we’re at a bit of a loss to explain it.

Looking at the broader picture, this is yet another test where AMD’s cards do well against NVIDIA’s non-compute cards. Overall the R9 285 is 2-3x faster than the GTX 760 here.

Moving on, our fourth compute benchmark is FAHBench, the official Folding @ Home benchmark. Folding @ Home is the popular Stanford-backed research and distributed computing initiative that has work distributed to millions of volunteer computers over the internet, each of which is responsible for a tiny slice of a protein folding simulation. FAHBench can test both single precision and double precision floating point performance, with single precision being the most useful metric for most consumer cards due to their low double precision performance. Each precision has two modes, explicit and implicit, the difference being whether water atoms are included in the simulation, which adds quite a bit of work and overhead. This is another OpenCL test, utilizing the OpenCL path for FAHCore 17.

Compute: Folding @ Home: Explicit, Single Precision

Compute: Folding @ Home: Implicit, Single Precision

When it comes to single precision the R9 285 edges out the R9 280, though not significantly so. R9 285 still seemingly benefits from some of the GCN 1.2 architectural optimizations, but not to the same extent we’ve seen in other benchmarks.

Overall AMD’s GCN cards are a strong performer in this benchmark and the R9 285 is no exception. GTX 760 trails R9 285 when it comes to implicit single precision, and is blown away in the explicit single precision benchmark.

Compute: Folding @ Home: Explicit, Double Precision

Meanwhile for double precision the R9 285 falls well behind the R9 280. Since Tonga is not designed to pull double-duty as a graphics and high performance compute GPU like Tahiti was, Tonga is configured for 1/16 rate double precision performance, 1/4 the rate of the more powerful Tahiti. As a result it can never keep up with the R9 280 in a double precision workload. Consequently AMD and the R9 285 still have a lead in F@H with double precision, but not to the degree we’ve seen elsewhere. The R9 285 is only about 30% faster than the GTX 760 here.

Wrapping things up, our final compute benchmark is an in-house project developed by our very own Dr. Ian Cutress. SystemCompute is our first C++ AMP benchmark, utilizing Microsoft’s simple C++ extensions to allow the easy use of GPU computing in C++ programs. SystemCompute in turn is a collection of benchmarks for several different fundamental compute algorithms, with the final score represented in points. DirectCompute is the compute backend for C++ AMP on Windows, so this forms our other DirectCompute test.

Compute: SystemCompute v0.5.7.2 C++ AMP Benchmark

SystemCompute exposes another case where the R9 285 comes up short compared to the R9 280, though only slightly. AMD’s latest card can deliver 93% of the performance of an R9 280, and most likely it’s suffering just a bit from the reduction in memory bandwidth. Otherwise it’s still more than 50% ahead of the GTX 760 and still comfortably ahead of the more powerful GTX 770.

Synthetics Power, Temperature, & Noise
Comments Locked

86 Comments

View All Comments

  • TiGr1982 - Thursday, September 11, 2014 - link

    BTW, is Tonga the only new GPU AMD has to offer in 2014?
    (if I'm not mistaken, the previous one from AMD, Hawaii, was released back in October 2013, almost a year ago)
    Does anybody know?
  • HisDivineOrder - Thursday, September 11, 2014 - link

    The thing is the moment I heard AMD explaining how Tonga was too new for current Mantle applications, I was like, "And there the other shoe is dropping."

    The promise of low level API is that you get low level access and the developer gets more of the burden of carrying the optimizations for the game instead of a driver team. This is great for the initial release of the game and great for the company that wants to have less of a (or no) driver team, but it's not so great for the end user who is going to wind up getting new cards and needing that Mantle version to work properly on games no longer supported by their developer.

    It's hard enough getting publishers and/or developers to work on a game a year or more after release to fix bugs that creep in and in some cases hard to get them to bother with resolution switches, aspect ratio switches, the option to turn off FXAA, the option to choose a software-based AA of your choice, or any of a thousand more doohickeys we should have by now as bog-standard. Can you imagine now relying on that developer--many of whom go completely out of business after finishing said title if they happen to work for Activision or EA--to fix all the problems?

    This is why a driver team is better working on it. Even though the driver team may be somewhat removed from the development of the game, the driver team continues to have an incentive to want to fix that game going forward, even if it's a game no longer under development at the publisher. You're going to be hard pressed to convince Bobby Kotick at Activision that it's worth it to keep updating versions of games older than six months (or a year for Call of Duty) because at a certain point, they WANT you to move on to another game. But nVidia and AMD (and I guess Intel?) want to make that game run well on next gen cards to help you move.

    This is where Mantle is flawed and where Mantle will never recover. Every time they change GCN, it's going to wind up with a similar problem. And every time they'll wind up saying, "Just switch to the DX version." If Mantle cannot be relied upon for the future, then it is Glide 2.0.

    And why even bother at all? Just stick with DirectX from the get-go, optimize for it (as nVidia has shown there is plenty of room for improvement), and stop wasting any money at all on Mantle since it's a temporary version that'll rapidly be out of date and unusable on future hardware.
  • The-Sponge - Thursday, September 11, 2014 - link

    I do not understand how they got there R9 270x temperatures, my OC'd R9 270x never even comes close to the temps they got....
  • mac2j - Friday, September 12, 2014 - link

    It's great that they've caught up with H.264 on hardware and the card otherwise looks fine. The bottom line for me, though, is that I don't see the point of buying card now without H.265 on hardware and an HDMI 2.0 port - 2 things Maxwell will bring this year. I haven't heard what AMDs timetable is there though.
  • P39Airacobra - Friday, October 17, 2014 - link

    It really irritates me that they are making these cards throttle to keep power and temps down! That is pathetic! If you can't make the thing right just don't make it! Even if it throttles .1mhz it should not be tolerated! We pay good money for this stuff and we should get what we pay for! It looks like the only AMD cards worth anything are the 270's and under. It stinks you have to go Nvidia to get more power! Because Nvidia really rapes people with their prices! But I must say the GTX 970 is priced great if it is still around $320. But AMD should have never even tried with this R9 285! First of all when you pay that much you should get more than 2GB. And another thing the card is pretty much limited to the performance of the R9 270's because of the V-Ram count! Yeah the 285 has more power than the 270's, But whats the point when you do not have enough V-Ram to take the extra power were you need a card like that to be? In other words if you are limited to 1080p anyway, Why pay the extra money when a R7 265 will handle anything at 1080p beautifully? This R9 285 is a pointless product! It is like buying a rusted out Ford Pinto with a V-8 engine! Yeah the engine is nice! But the car is a pos!
  • P39Airacobra - Friday, January 9, 2015 - link

    (QUOTE) So a 2GB card is somewhat behind the times as far as cutting edge RAM goes, but it also means that such a card only has ¼ of the RAM capacity of the current-gen consoles, which is a potential problem for playing console ports on the PC (at least without sacrificing asset quality).

    (SIGH) So now even reviewers are pretending the consoles can outperform a mid range GPU! WOW! How about telling the truth like you did before you got paid off! The only reason a mid range card has problems with console ports is because they are no longer optimized! They just basically make it run on PC and say xxxx you customers here it is! And no the 8GB on the consoles are used for everything not for only V-Ram! We are not stupid idiots that fall for anything like the idiots in Germany back in the 1930's!

Log in

Don't have an account? Sign up now