AMD Dual-Fiji “Gemini” Video Card Delayed To 2016, Aligned With VR Headset Launches
by Ryan Smith on December 22, 2015 10:35 PM ESTI’m going to start off this post a little differently tonight. Since our DX12 Ashes of the Singularity article back in October, I have been looking for an opportunity to do a bit of deep analysis on the current state of SLI, Crossfire, and Alternate Frame Rendering technology. I had expected that chance to come along when AMD launched their dual-GPU Fiji card in 2015. However as AMD is now confirming the card is not launching this year, clearly things have changed. Instead we’re now looking at a 2016 launch for that card, and in light of AMD publicly commenting on the fact that they are going to be focused on VR with the card, now is probably the best time to have that discussion about AFR in order to offer some more insight on AMD’s strategy.
But first, let’s get to the big news for the day: the status of AMD’s dual-GPU Fiji card, codename Gemini. As our regular readers likely recall, back at AMD’s Fiji GPU launch event in June, the company showed off four different Fiji card designs. These were the Radeon R9 Fury X, the R9 Fury, the R9 Nano, and finally the company’s then-unnamed dual-GPU Fiji card (now known by the codename Gemini). At the time Gemini was still in development – with AMD showing off an engineering sample of the board – stating that they expected the card to be released in the fall of 2015.
AMD GPU Specification Comparison | ||||||
AMD Radeon R9 Fury X | AMD Radeon R9 Fury | AMD Radeon R9 Nano | AMD Gemini (Dual Fiji Card) |
|||
Stream Processors | 4096 | 3584 | 4096 | 2 x ? | ||
Texture Units | 256 | 224 | 256 | 2 x ? | ||
ROPs | 64 | 64 | 64 | 2 x 64 | ||
Boost Clock | 1050MHz | 1000MHz | 1000MHz | ? | ||
Memory Clock | 1Gbps HBM | 1Gbps HBM | 1Gbps HBM | ? | ||
Memory Bus Width | 4096-bit | 4096-bit | 4096-bit | 2 x 4096-bit | ||
VRAM | 4GB | 4GB | 4GB | 2 x 4GB | ||
FP64 | 1/16 | 1/16 | 1/16 | 1/16 | ||
TrueAudio | Y | Y | Y | Y | ||
Transistor Count | 8.9B | 8.9B | 8.9B | 2 x 8.9B | ||
Typical Board Power | 275W | 275W | 175W | ? | ||
Manufacturing Process | TSMC 28nm | TSMC 28nm | TSMC 28nm | TSMC 28nm | ||
Architecture | GCN 1.2 | GCN 1.2 | GCN 1.2 | GCN 1.2 | ||
GPU | Fiji | Fiji | Fiji | Fiji | ||
Launch Date | 06/24/15 | 07/14/15 | 09/10/15 | 2016 | ||
Launch Price | $649 | $549 | $649 | (Unknown) |
However since that original announcement we haven’t heard anything further about Gemini, with AMD/RTG more focused on launching the first three Fiji cards. But with today marking the start of winter, RTG has now officially missed their original launch date for the card.
With winter upon us, I reached out to RTG last night to find out the current status of Gemini. The response from RTG is that Gemini has been delayed to 2016 to better align with the launch of VR headsets.
The product schedule for Fiji Gemini had initially been aligned with consumer HMD availability, which had been scheduled for Q415 back in June. Due to some delays in overall VR ecosystem readiness, HMDs are now expected to be available to consumers by early Q216. To ensure the optimal VR experience, we’re adjusting the Fiji Gemini launch schedule to better align with the market.
Working samples of Fiji Gemini have shipped to a variety of B2B customers in Q415, and initial customer reaction has been very positive.
And as far as video card launches go – and this will be one of the oddest things I’ve ever said – I have never before been relieved to see a video card launch delayed. Why? Because of the current state of alternate frame rendering.
Stepping to the side of the Gemini delay for the moment, I want to talk a bit about internal article development at AnandTech. Back in November when I was still expecting a November/December launch for Gemini, I began doing some preliminary planning for the Gemini review. What cards/setups we’d test, what games we’d use, resolutions and settings, etc. The potential performance offered by dual-GPU cards (and multi-GPU setups in general) means that to properly test them we need to put together some more strenuous tests to fit their performance profile, and we also need to assemble scenarios to evaluate other factors such as multi-GPU scaling and frame pacing consistency. What I found for testing disappointed me.
To cut right to the chase, based on my preliminary planning, things were (and still are) looking troubled for the current state of AFR. Game compatibility in one form or another in recently launched games is the lowest I’ve ever seen it in the last decade, which is rendering multi-GPU setups increasingly useless for improving gaming performance. For that reason, back in November I was seriously considering how I would go about broaching the matter with RTG; how to let them know point blank (and before I even reviewed the card) that Gemini was going to fare poorly if reviewed as a traditional high-performance video card. That isn’t the kind of conversation I normally have with a manufacturer, and it’s rarely a good thing when I do.
This is why as awkward as it’s going to be for RTG to launch a dual-GPU 28nm video card in 2016, that I’m relieved that RTG has pushed back the launch of the card. Had RTG launched Gemini this year as a standard gaming card, they would have run straight into the current problems facing AFR. Instead by delaying it to 2016 and focusing on VR – one of the only use cases that still consistently benefits from multi-GPU setups – RTG gets a chance to salvage their launch and their engineering efforts. There’s definitely an element of making the most of a bad situation here, as RTG is going to be launching Gemini in the same year we finally expect to see FinFET GPUs, but it’s going to be the best course of action they can take at this time.
The Current State of Multi-GPU & AFR
I think it’s fair to say that I am slightly more conservative on multi-GPU configurations than other PC hardware reviewers, as my typical advice is to hold-off on multi-GPU until you’ve exhausted single GPU performance upgrades. In the right situations multi-GPU is a great way to add performance, offering performance greater than any single GPU, but in the wrong scenarios it can add nothing for performance, or worse it can drive performance below that of a single GPU.
The problem facing RTG (and NVIDIA as well) is that game compatibility with alternate frame rendering – the heart of SLI and CrossFire – is getting worse and worse, year by year. In preparing for the Gemini review I began looking at new games, and the list of games that came up with issues was longer than ever before.
AFR Compatibility (Fall 2015) | |||
Game | Compatibility | ||
Batman: Arkham Knight | Not AFR Compatible | ||
Just Cause 3 | Not AFR Compatible | ||
Fallout 4 | 60fps Cap, Tied To Game Sim Speed | ||
Anno 2205 | Not AFR Compatible | ||
Metal Gear Solid V: The Phantom Pain | 60fps Cap, Tied To Game Physics | ||
Star Wars Battlefront | AFR Compatible | ||
Call of Duty: Black Ops III | AFR Compatible |
Out of the 7 games I investigated, 3 of them outright did not (and will not) support multi-GPU. Furthermore another 2 of them had 60fps framerate caps, leading to physics simulation issues when the cap was lifted. As a result there were only two major fall of 2015 games that were really multi-GPU ready: Call of Duty: Black Ops III and Star Wars Battlefront.
I’ll first start things off with the subject of framerate caps. As far as framerate caps go, while these aren’t a deal-breaker for mutli-GPU use, as benchmarks they’re not very useful. But more importantly I would argue that the kind of gamers investing in a high-end multi-GPU setup are also the kind of gamers that are going to want higher framerates than 60fps. Next to 4K gaming, the second biggest use case for multi-GPU configurations is to enable silky-smooth 120Hz/144Hz gaming, something that has been made far more practical these days thanks to the introduction of G-Sync and Freesync. Unfortunately even when you can remove the cap, in the cases of both Fallout 4 and Metal Gear Solid V the caps are tied to the games’ simulations. As a result removing the cap can break the game in minor ways (MGSV’s grenades) or major ways (Fallout 4’s entire game speed). Consequently multi-GPU users are left with the less than palatable choice of limiting the usefulness of their second GPU, or breaking the game in some form.
But more concerning are the cases where AFR is outright incompatible. I touched upon this a bit in our DX12 Ashes article, that games are increasingly using rendering methods that are either inherently AFR incompatible, or at best are so difficult to work around that the development time and/or performance gains aren’t worth it. AFR incompatible games aren’t a new thing, as we’ve certainly had those off and on for years now – but I cannot recall a time where so many major releases were incompatible.
The crux of the issue is that game engines are increasingly using temporal reprojection and similar techniques in one form or another in order to create more advanced effects. The problem with temporal reprojection is, as implied by the name, it requires reusing data from past frames. For a single GPU setup this is no problem and it allows for some interesting effects to be rendered with less of a performance cost than would otherwise be necessary. However this is a critical problem for multi-GPU setups due to the fact that AFR means that while one GPU is still rendering frame X, the other GPU needs to start rendering frame X+1.
Temporal reprojection In Lords of the Fallen (Top) and the Frostbite Engine (Bottom)
Frame interdependency problems like this have been at the heart of a lot of AFR issues over the years, and a number of workarounds have been developed to make AFR continue to work, typically at the driver level. In easier cases the cost is that there is some additional synchronization required, which brings down the performance gains from a second GPU. However in harder cases the workarounds can come with a higher performance hit (if the problem can be worked around at all), to the point where additional GPUs aren’t an effective means to improve performance.
Ultimately the problem is that in the short-to-mid run, these kinds of issues are going to get worse. Developers are increasingly using AFR-unfriendly rendering techniques. And in this age of multiplatform releases where big-budget AAA games are simultaneously developed for two consoles and the PC, PC users are already a minority of sales, and multi-GPU users are a smaller fraction still. Consequently from a developer’s perspective – one that by the numbers needs to focus on consoles first and the PC second – AFR is something of a luxury that typically cannot come before creating an efficient renderer for the consoles.
Which is not to say that AFR is doomed. DirectX 12’s explicit multi-adapter modes are designed in part to address this issue by giving developers direct control over how multiple GPUs are assigned work and work together in a system. However it is going to take some unknown amount of time for the use of DirectX 12 in games to ramp up – with the delay of the Fable Legends the first DX12 games will not be released until 2016 – so until that happens we’re left with the status quo of DirectX 11 and driver-assisted AFR. And that ultimately means that 2015 is a terrible time to launch a product heavily reliant on AFR.
Virtual Reality: The Next Great Use Case for Multi-GPU
That brings me to the second point of today’s analysis, which is what one possible future for multi-GPU setups may be. If AFR is increasingly unreliably due to frame interdependency issues, then if multi-GPU configurations are going to improve performance, then there needs to be a way to use multiple GPUs where frames are minimally dependent on each other. As it turns out, stereoscopic virtual reality is just such a use case.
In its most basic implementation, stereoscopic VR involves rendering the same scene twice: once for each eye (view), with the position of the camera slightly offset to mimic how human eyes are separated. There are a number of optimizations that can be done here to reduce the workload, but in the end many parts of a scene need to be completely re-rendered because the second view can see things (or sees things slightly differently) than the first view.
The beauty of stereoscopic rendering as far as multi-GPU is concerned is that because each view is rendering the same scene, there’s little-to-no interdependency between what each view is doing; one view doesn’t affect the other. This means that assigning a GPU to each view is a relatively straightforward operation. And if rendering techniques like temporal reprojection are in use, those again are per-view, so each GPU can reference its past frame in a single-GPU like manner.
At the same time because VR requires rerendering large parts of a frame twice, coupled with the need for low latency it has very high performance requirements, especially if you want to make the jump to VR without significantly compromising on image quality. The recommended system requirements for the Oculus Rift are a Radeon R9 290, a GeForce GTX 970, or equivalent. And if users want better performance or developers want better looking games, then a still more powerful setup is required.
This, in a nutshell, is why VR is the next great use case for multi-GPU setups. There is a significant performance need, and VR rendering is much friendlier to multi-GPU setups. RTG and NVIDIA are in turn both well aware of this, which is why both of them have multi-GPU technologies in their SDKs, Affinity Multi-GPU and VR SLI respectively.
Gemini: The Only Winning Move Is To Play VR
Finally, bringing this back to where I began, we have RTG’s Gemini. If you go by RTG’s statements, they have been planning to make Gemini a VR card since the beginning. And truthfully I have some lingering doubts about this, particularly because the frontrunner VR headset, the Oculus Rift, was already had a Q1’16 launch schedule published back in May, which was before AMD’s event. But at the same time I will say that RTG was heavily showing off VR at their Fiji launch event in June, and the company had announced LiquidVR back in March.
Regardless of what RTG’s original plans were though, I believe positioning Gemini as a video card for VR headsets is the best move RTG can make at this time. With the aforementioned AFR issues handicapping multi-GPU performance in traditional games, releasing Gemini now likely would have been a mistake for RTG from both a reviews perspective and a sales perspective. There will always be a market for multi-GPU setups, be it multiple cards or a singular multi-GPU card, but that market is going to be far smaller if AFR compatibility is poor, as multi-GPU is a significant investment for many gamers.
As for RTG, for better and for worse at this point they have tied Gemini’s future to the actions of other companies, particularly Oculus and HTC. The good news is that even with the most recent delay on the HTC Vive, both companies appear to be ramping up for their respective releases, with word coming just today that game developers have started receiving finalized Rift units for testing. Similarly, both companies are now targeting roughly the same launch window, with the Rift set to arrive in Q1’16 (presumably late in the quarter), and the Vive a month later in April. The risk then for RTG is whether these units arrive in large enough numbers to help Gemini reach RTG’s sales targets, or if the ramp-up for VR will bleed over into what’s expected to be the launch of FinFET GPUs. As is typically the case, at this point only time will tell.
43 Comments
View All Comments
The_Assimilator - Wednesday, December 23, 2015 - link
I will be very surprised if Gemini is actually ever delivered. End of 2015 was already pushing it, Q1 2016 means it's going to be arriving on outdated 28nm tech just as 14nm Pascal makes its debut in Q2. Assuming no delays on nVidia's part, and that they don't release a lemon, that gives Gemini 3 months in the spotlight, tops. That's just not enough for an expensive dual-GPU card.Re the article, I don't think it's fair to include Arkham Knight in a list of "Fall 2015 New Games". That game's been out since early 2015 and is so horribly broken I get the feeling both nVidia and AMD have washed their hands of it. As for Fallout 4 and MGS V, they're locked to 60FPS because they're console ports.
The_Assimilator - Wednesday, December 23, 2015 - link
Ugh, 16nm Pascal.Vayra - Thursday, December 24, 2015 - link
No, Fallout 4 is not FPS locked at all, the engine just doesn't like frame variance too much.edzieba - Wednesday, December 23, 2015 - link
On the flipside, multi-GPU VR has to be designed in during game engine development, optimised by the game developer per game (to avoid introducing extra latency rather than reducing it), and mainly accelerates pixel-based operations rather than geometry and lighting operations. The 'per eye' resolution of upcoming consumer headsets (1080x1200 for both the Vive and Rift CV1) are relatively low. You can 'push up' pixel operations by using SSAA rather than MSAA (MSAA is effectively a requirement for VR to prevent highly visible aliasing), but that's more using brute force just as an excuse for overspeccing.Worse, the design requirements for VR (very fine up-close detail, 'cheats' like normal mapping not working well in stereo) put emphasis on geometric detail, something that multi-GPU VRm does not effectively accelerate (you need to duplicate most or all of that work, or you're stuck wasting precious latency talking over the PCIe bus). You also have a fixed (albeit small) latency overhead due to having to copy the buffer from one card to another before compositing the two buffers for output.
VR multi-GPU has the same or worse issues as currently exist with multi-GPU compatibility, and even in the optimum case can't even approach perfect scaling.
owan - Wednesday, December 23, 2015 - link
Wtf is RTG? Can we just call it AMD instead of the acronym nobody knows for the stupid name they gave an internal division? It's confusing and pointless.testbug00 - Thursday, December 24, 2015 - link
Radeon Technologies Group.It is the "internal division" which now runs ALL of the graphics stuff. Think of it as a sub-company. Calling it RTG is completely fine.
owan - Monday, January 4, 2016 - link
I know exactly what it stands for, but the point is that its a stupid new acronym that AMD have created to separate their GPU division from the lifeless husk of their CPU division to prepare for the inevitable spin-off. Even so, the AMD brand (or ATI) have a lot more meaning to me than "RTG"jasonelmore - Saturday, December 26, 2015 - link
Dollars to Doughnuts AMD PR is Hammering "RTG" into all tech writers heads.. they are probably requiring it or else they get no samples.Ryan Smith - Tuesday, December 29, 2015 - link
When I asked the RTG what they would prefer we use, they said that they'd prefer we use their name as opposed to AMD.The fact of the matter is that there's a distinct lack of "AMD" in the latest RTG slide decks, and that's intentional on their part.
hero4hire - Saturday, January 9, 2016 - link
However a company wishes to brand itself, it takes time for us to absorb the new name. Out of respect for the about to be spun off RTG I understand using their preferred name. But for the sake of the readers please reference AMD/RTG as you did in the past during the ATI/AMD change. It is confusing to translate