AMD Dual-Fiji “Gemini” Video Card Delayed To 2016, Aligned With VR Headset Launches

I’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.

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.

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.