Practical Performance Possibilities

Last but not least, we would like to explore the potential performance repercussions of the GTX 970’s unusual configuration.

Starting with the ROPs, while NVIDIA’s original incorrect specification is unfortunate, from a practical perspective it’s really just annoying. As originally (and correctly) pointed out by The Tech Report and Hardware.fr, when it comes to fillrates the GTX 970 is already bottlenecked elsewhere. With a peak pixel rate of 4 pixels per clock per SMM, the GTX 970’s 13 SMMs inherently limit the card to 52px/clock, versus the 56px/clock rate for the card’s 56 ROPs. This is distinct from the GTX 980, where every stage of the GPU can pump out 64px/clock, and the ROPs can consume it just as well. In the case of the GTX 970 those extra ROPs still play a role in other tasks such as MSAA and other ROP activities that don’t require consuming additional SMM output – not to mention a fully disabled ROP/MC partition would shift the bottleneck to the ROPs with only 48 ROPs vs. 13 SMMs – so the 56 ROPs are still useful to have, but for basic pixel operations the GTX 970 has been bound by its SMM count from the start.

As for the memory segmentation, there are 3 basic scenarios to consider, only one of which has the potential to impact the GTX 970 in particular. In all cases with less than 3.5GB of memory allocated the GTX 970 behaves just as if it had a single segment, with no corner cases to be concerned about. Meanwhile in cases with more than 4GB of memory allocation the GTX 970 will still spill over to PCIe, just as the GTX 980 does, typically crushing performance in both cases. This leaves the last case as the only real concern, which is memory allocations between 3.5GB and 4GB.

GeForce GTX 970 Theoretical Memory Bandwidth
Segment Memory
Fast Segment (3.5GB) 192GB/sec
Slow Segment (512MB) 28GB/sec
PCIe System Memory 16GB/sec

In the case of memory allocations between 3.5GB and 4GB, what happens is unfortunately less-than-deterministic. The use of heuristics to determine which resources to allocate to which memory segment, though the correct solution in this case, means that the real world performance impact is going to vary on a game-by-game basis. If NVIDIA’s heuristics and driver team do their job correctly, then the performance impact versus a theoretical single-segment 4GB card should only be a few percent. Even in cases where the entire 4GB space is filled with in-use resources, picking resources that don’t need to be accessed frequently can sufficiently hide the lack of bandwidth from the 512MB segment. This is after all just a permutation on basic caching principles.

The worst case scenario on the other hand would be to have the NVIDIA heuristics fail, or alternatively ending up with a workload where no great solution exists, and over 3.5GB of resources must be repeatedly and heavily accessed. In this case there is certainly the potential for performance to crumple, especially if accessing resources in the slow segment is a blocking action. And in this case the GTX 970 would still perform better than a true 3.5GB card since the slow segment is still much faster than system memory, but it’s nonetheless significantly slower than the 3.5GB segment as well.

But perhaps the most frustrating scenario isn’t having more than 3.5GB of necessary resources, but having more than 3.5GB of unnecessary resources due to caching by the application. One VRAM utilization strategy for games is to allocate as much VRAM as they can get their hands on and then hold onto it for internal resource caching, increased view distances, or other less immediate needs. The Frostbite engine behind the Battlefield series (and an increasing number of other EA games) is one such example, as it will opportunistically allocate additional VRAM for the purpose of increasing draw distances. For something like a game this actually makes a lot of sense at the application level – games are generally monolithic applications that are the sole program being interacted with at the time – but it makes VRAM allocation tracking all the trickier as it obfuscates what a game truly needs versus what it merely wants to hold onto for itself. In this case tracking resources by usage is still one option, though like the overall theme of real world performance implications, it’s going to be strongly dependent on the individual application.

In any case, the one bit of good news here is that for gaming running out of VRAM is generally rather obvious. Running out of VRAM, be it under normal circumstances or going over the GTX 970’s 3.5GB segment, results in some very obvious stuttering and very poor minimum framerates. So if it does happen then it will be easy to spot. Running out of (fast) VRAM isn’t something that can easily be hidden if the VRAM is truly needed.

To that end in the short amount of time we’ve had to work on this article we have also been working on cooking up potential corner cases for the GTX 970 and have so far come up empty, though we’re by no means done. Coming up with real (non-synthetic) gaming workloads that can utilize between 3.5GB and 4GB of VRAM while not running into a rendering performance wall is already a challenge, and all the more so when trying to find such workloads that actually demonstrate performance problems. This at first glance does seem to validate NVIDIA’s overall claims that performance is not significantly impacted by the memory segmentation, but we’re going to continue looking to see if that holds up. In the meantime NVIDIA seems very eager to find such corner cases as well, and if there are any they’d like to be able to identify what’s going on and tweak their heuristics to resolve them.

Ultimately we find ourselves going a full circle back to something NVIDIA initially said about the matter, which is that the performance impact of the GTX 970’s configuration is already baked into the results we have. After all, the configuration is not a bug or other form of unexpected behavior, and NVIDIA has been fully abstracting and handling the memory segments since the GTX 970’s initial launch. So while today’s revelation gives us a better understanding of how GTX 970 operates and what the benefits and drawbacks are, that information alone doesn’t change how the card behaves.

Closing Thoughts

Bringing things to a close, I must admit I was a bit taken aback when NVIDIA first told us that they needed to correct the specifications for the GTX 970. We’ve had NVIDIA decline to disclose sensitive information before only to reveal it later, but they’ve never had to do something quite like this before. In retrospect these new specifications make more sense given the performance and device specs we’re seeing, but it certainly is going to leave egg on NVIDIA’s face as this never should have happened in the first place.

As for the GTX 970’s underlying memory configuration and memory allocation techniques, this is going to be a more difficult matter to bring closure to. Without question the GTX 970’s unusual memory configuration introduces a layer of complexity that isn’t there with the GTX 980, and as a result it’s extremely difficult to quantify better and worse in this case. It’s worse than the GTX 980 – and it is a lower tier card after all – but how much worse is no longer an easy answer to provide.

At its heart the GTX 970’s configuration is a compromise between GPU yields, card prices, and memory capacity. The easiest argument to make in that regard is that it should have shipped with a full 64 ROP configuration and skipped all of these complexities entirely. But on the whole and looking at the options for configurations without this additional complexity, a 3GB/48 ROP GTX 970 would have been underspeced, and with so much of the GTX 970’s success story being NVIDIA’s ability to launch the card at $329 I’m not sure if the other option is much better. At least on paper this looks like the best compromise NVIDIA could make.

In the end while I am disappointed that these details haven’t come out until now, I am satisfied that we now finally have enough information in hand to truly understand what’s going on with the GTX 970 and what its strengths and weaknesses are as a result of memory segmentation. Meanwhile for real world performance, right now this is an ongoing test with the GTX 970. As the highest-profile card to use memory segmentation it’s the first time NVIDIA has been under the microscope like this, but it’s far from the first time they’ve used this technology. But so far with this new information we have been unable to break the GTX 970, which means NVIDIA is likely on the right track and the GTX 970 should still be considered as great a card now as it was at launch. In which case what has ultimately changed today is not the GTX 970, but rather our perception of it.

Segmented Memory Allocation in Software
Comments Locked

398 Comments

View All Comments

  • MrWhtie - Thursday, January 29, 2015 - link

    "they set themselves up to hike prices in the future" hyperbole at its finest. Try again once you calm down and start speaking with some logic and reason.
  • Casecutter - Wednesday, January 28, 2015 - link

    ^ It's simple they can't... They fused off one damaged defective L2 as they didn't have the volume of good GM204 to go to market with enough 970 parts. I would believe that the GTX 980M is a 12SMX part alought has all the L2 as the GTX980. They realy screw th pouch by touting "the GTX 970 ships with THE SAME MEMORY SUBSYSTEM AS OUR FLAGSHIP GEFORCE GTX 980".

    Nvidia came out and said "This team (PR) was unaware that with "Maxwell," you could segment components previously thought indivisible, or that you could "partial disable" components."

    Had Nvidia called it 3.5Gb with Active Boost... or 4Gb Memory Compression... or something like that and explained I think a lot of folks would've taken interest and weigh that when making a choice... But we weren't privy to that information.
  • Elixer - Wednesday, January 28, 2015 - link

    Looks like Nvidia is trying to make good.

    They will help you get a refund/credit for your 970 if you feel you want one.

    http://forums.anandtech.com/showpost.php?p=3712051...

    "I totally get why so many people are upset. We messed up some of the stats on the reviewer kit and we didn't properly explain the memory architecture. I realize a lot of you guys rely on product reviews to make purchase decisions and we let you down.

    It sucks because we're really proud of this thing. The GTX970 is an amazing card and I genuinely believe it's the best card for the money that you can buy. We're working on a driver update that will tune what's allocated where in memory to further improve performance.

    Having said that, I understand that this whole experience might have turned you off to the card. If you don't want the card anymore you should return it and get a refund or exchange. If you have any problems getting that done, let me know and I'll do my best to help."
  • MrWhtie - Wednesday, January 28, 2015 - link

    Yeah right, they can't have my 970 back :P What am I going to buy instead, an AMD? (LOL!)
  • CX71 - Wednesday, January 28, 2015 - link

    > "What am I going to buy instead, an AMD? (LOL!)"
    That would be a good move ... TROLOLOLOLOL
  • mudz78 - Wednesday, January 28, 2015 - link

    That's great news. Good see a company owning their mistakes and doing the right thing by consumers.

    The GTX 970 is still a good card, but purchasers have a right to make an informed decision before handing over their hard earned dollars.
  • Man_Of_Steele - Thursday, January 29, 2015 - link

    If they really are accepting returns and refunds regardless of when you purchased your card, that would make this seem like it really was an honest mistake - despite the mistake seeming highly unlikely.
    As for me, 3.5gb VRAM isn't enough to justify $350-$400 (EVGA SC or SSC). I will wait and see what AMD does with the 390x, and wait and see if nVIDIA launches an 8gb (read 7gb) 970
  • Man_Of_Steele - Wednesday, January 28, 2015 - link

    I understand that the cache isn't a huge issue, but as far as a future proof card, only 3.5gb VRAM..?
    You guys can form your own opinions, but that is a lot of people within the company that this error just so happened to slip past. There is also a notable stutter in Shadow of Mordor for those who haven't seen that yet.

    What I am curious to see, is if there is a way to re-enable the ROPs and increase the clock on that last 500mb vram. This may be impossible and I'm just ignorant on the issue, but if someone knows please let me know if its possible!
  • MrWhtie - Thursday, January 29, 2015 - link

    I don't think its possible, that last 500mb is slow because it only has one of its ROP/L2 units disabled (compared with 8 fully active on the 980). This causes one of the remaining ROP/L2 units to communicate with TWO of the 500mb DRAM sections (instead of 8 ROP/L2 each with their own 500mb DRAM.) Since it cannot access both 500mb secitions at once, it can only use 500mb in a "fast mode". When it tries to access both the speed is cut in half since normal operation is ONE ROP per 500mb DRAM. (The diagram on the second page illustrates this.)

    Its a hardware thing, its not a software issue whatsoever.
  • Man_Of_Steele - Thursday, January 29, 2015 - link

    I saw the diagrams on a couple different sites, I just wasn't sure if they disabled it the smart way or the lazy way.
    Thanks for the clarification!

Log in

Don't have an account? Sign up now