GeForce + Radeon: Previewing DirectX 12 Multi-Adapter with Ashes of the Singularity
by Ryan Smith on October 26, 2015 10:00 AM ESTAshes GPU Performance: Single & Mixed 2012 GPUs
While Ashes’ mutli-GPU support sees solid performance gains with current-generation high-end GPUs, we wanted to see if those gains would extend to older DirectX 12 GPUs. To that end we’ve put the GeForce GTX 680 and the Radeon HD 7970 through a similar test, running the Ashes’ benchmark at 2560x1440 with Medium image quality and no MSAA.
First off, unlike our high-end GPUs there’s a distinct performance difference between our AMD and NVIDIA cards. The Radeon HD 7970 performs 22% better here, just averaging 30fps to the GTX 680’s 24.5fps. So right off the bat we’re entering an AFR setup with a moderately unbalanced set of cards.
Once we do turn on AFR, two very different things happen. The GTX 680 + HD 7970 setup is an outright performance regression, with performance 40% from the single GTX 680 Ti. On the other hand the HD 7970 + GTX 680 setup sees an unexpectedly good performance gain from AFR, picking up a further 55% to 46.4fps.
As this test is a smaller number of combinations it’s not clear where the bottlenecks are, but it’s none the less very interesting how we get such widely different results depending on which card is in the lead. In the GTX 680 + HD 7970 setup, either the GTX 680 is a bad leader or the HD 7970 is a bad follower, and this leads to this setup spinning its proverbial wheels. Otherwise letting the HD 7970 lead and GTX 680 follow sees a bigger performance gain than we would have expected for a moderately unbalanced setup with a pair of cards that were never known for their efficient PCIe data transfers. So long as you let the HD 7970 lead, at least in this case you could absolutely get away with a mixed GPU pairing of older GPUs.
Facebook
Twitter
RSS
180 Comments
View All Comments
jimjamjamie - Tuesday, October 27, 2015 - link
[pizza-making intensifies]geniekid - Monday, October 26, 2015 - link
On one hand the idea of unlinked EMA is awesome. On the other hand, I have to believe 95% of developers will shy away from implementing anything other than AFR in their game due to the sheer amount of effort the complexity would add to their QA/debugging process. If Epic manages to pull off their post-processing offloading I would be very impressed.DanNeely - Monday, October 26, 2015 - link
I'd guess it'd be the other way around. SLI/XFire AFR is complicated enough that it's normally only done for big budget AAA games. Other than replacing two vendor APIs with a single OS API DX12 doesn't seem to offer a whole lot of help there; so I don't expect to see a lot change.Handing off the tail end of every frame seems simpler; especially since the frame pacing difficulties that make AFR so hard and require a large amount of per game work won't be a factor. This sounds like something that could be baked into the engines themselves, and that shouldn't require a lot of extra work on the game devs part. Even if it ends up only being a modest gain for those of us with mid/high end GPUs; it seems like it could end up being an almost free gift.
nightbringer57 - Monday, October 26, 2015 - link
That's only half relevant.I wonder how much can be implemented at the engine level. This kind of thing may be at least partially transparent to devs if says Unreal Engine and Unity get compatibility for it... I don't know how much it can do, though.
andrewaggb - Monday, October 26, 2015 - link
Agreed, I would hope that if the Unreal Engine, Unity, Frostbite etc support it that maybe 50% or more of new games will support it.We'll have to see though. The idea of having both an AMD and Nvdia card in the same machine is both appealing and terrifying. Occasionally games work better on one than the other, so you might avoid some pain sometimes, but I'm sure you'd get a whole new set of problems sometimes as well.
I think making use of the iGPU and discrete cards is probably the better scenario to optimize for. (Like Epic is apparently doing)
Gigaplex - Monday, October 26, 2015 - link
Problems such as NVIDIA intentionally disabling PhysX when an AMD GPU is detected in the system, even if it's not actively being used.Friendly0Fire - Monday, October 26, 2015 - link
It really depends on a lot of factors I think, namely how complex the API ends up being.For instance, I could really see shadow rendering being offloaded to one GPU. There's minimal crosstalk between the two GPUs, the shadow renderer only needs geometry and camera information (quick to transfer/update) and only outputs a single frame buffer (also very quick to transfer), yet the process of shadow rendering is slow and complex and requires extremely high bandwidth internally, so it'd be a great candidate for splitting off.
Then you can also split off the post-processing to the iGPU and you've suddenly shaved maybe 6-8ms off your frame time.
Oogle - Monday, October 26, 2015 - link
Yikes. Just one more exponential factor to add when doing benchmarks. More choice is great for us consumers. But reviews and comparisons are going to start looking more complicated. I'll be interested to see how guys will make recommendations when it comes to multi-gpu setups.tipoo - Monday, October 26, 2015 - link
Wow, seems like a bigger boost than I had anticipated. Will be nice to see all that unused silicon (in dGPU environments) getting used.gamerk2 - Monday, October 26, 2015 - link
Drivers. Pretty much that simple. Odds are, the NVIDIA drivers are treating the HD 7970 the same way it's treating the 680 GTX, which will result in performance problems. AMD and NVIDIA use very different GPU architectures, and you're seeing it here. NVIDIA is probably attempting to utilize the 7970 in a way it just can't handle.
I'd be very interested to see something like 680/Titan, or some form of lower/newer setup, which is what most people would actually use this for (GPU upgrade).