TR Forums

This has been a topic that's been discussed in numerous places except for techreport.com. I'm not sure how big a concern it is, but even despite doing plenty of reading of speculation on the issue, I wanted to hear from those that frequented TR. That, and the fact that the TR review and system builds constantly put Nvidia's latest offerings in a good light.

If you're not familiar with the issue, Nvidia's GTX 970 is equipped with 4GB VRAM. However, users started noticing issues with memory allocation, quoting an average VRAM limitation of 3.5GB, and massive performance drops afterwards.



The screenshot shown above is a tool created specifically to test this issue. As shown in the picture, memory performance on the GTX 970 suffers greatly after roughly 3.3GB VRAM used.

Nvidia has yet to issue any official statement on the matter, other than the fact that "they'll look into it." Meanwhile, I was wondering how every single tech review site could have missed this glaring problem, including TR. To be fair, it's understandable since I wasn't even aware of this issue myself until I tested it. The benchmarks still show good numbers across the board as well. But regardless, this seems to be a severe problem that needs to be addressed. In the meantime, I was wondering (despite extensive reviews already having been done) how this would affect TR's recommendation of these latest cards.

I bought a 4GB video card, and knowing that I can only use about 3.5GB of it doesn't sit well with me.

But nvidia and intel do no wrong and dirty crappy also-ran amd should just go away already so the pc supply chain can be sunshine and rainbows!

(sarcasm, incase anyone's detector is broken)

I heard about this. I bet it's an unintentional (maybe known, but ultimately unintentional) hardware problem, or maybe firmware. I bet it's something to do with the way they disabled the SMMs on the GTX 970.

auxy wrote:

I heard about this. I bet it's an unintentional (maybe known, but ultimately unintentional) hardware problem, or maybe firmware. I bet it's something to do with the way they disabled the SMMs on the GTX 970.

thats my guess too - very unlikely its intentional
hopefully it a small bug they can fix in a new firmware or something
has there been any tests to see if the 980 is doing the same thing?

It is a known memory mapping problem with NT 6.x and earlier. It effects all GPUs with memory capacities greater than 4GiB. The OS were coded back when VRAM on GPU was less than 64MiB, so there's 32-bit code floating around.

*nix fixed the problem a while ago, so it is a non-issue.

Krogoth wrote:

It is a known memory mapping problem with NT 6.x and earlier. It effects all GPUs with memory capacities greater than 4GiB. The OS were coded back when VRAM on GPU was less than 64MiB, so there's 32-bit code floating around.

*nix fixed the problem a while ago, so it is a non-issue.

It clearly doesn't affect the 980 per information present IN THIS THREAD. It also doesn't affect my 290X, nor my TITAN.

Really, how you not choke to death on your own tongue?

auxy wrote:

Krogoth wrote:

It is a known memory mapping problem with NT 6.x and earlier. It effects all GPUs with memory capacities greater than 4GiB. The OS were coded back when VRAM on GPU was less than 64MiB, so there's 32-bit code floating around.

*nix fixed the problem a while ago, so it is a non-issue.

It clearly doesn't affect the 980 per information present IN THIS THREAD. It also doesn't affect my 290X, nor my TITAN.

Really, how you not choke to death on your own tongue?

Oh really?

http://www.overclock.net/t/1403641/gtx- ... -of-memory
http://www.gpugrid.net/forum_thread.php?id=3935

and that's top of a list of a simple google search.

It is a problem with Windows which Microsoft will most likely fix with Windows 10 and pitch as an excuse to "upgrade".

The only reason that this problem has become apparent is because 4GiB+ cards are much more commonplace and people are trying to see if its actually *needed*.

Krogoth wrote:

It is a known memory mapping problem with NT 6.x and earlier. It effects all GPUs with memory capacities greater than 4GiB. The OS were coded back when VRAM on GPU was less than 64MiB, so there's 32-bit code floating around.

*nix fixed the problem a while ago, so it is a non-issue.

Krogoth wrote:

auxy wrote:

Krogoth wrote:

It is a known memory mapping problem with NT 6.x and earlier. It effects all GPUs with memory capacities greater than 4GiB. The OS were coded back when VRAM on GPU was less than 64MiB, so there's 32-bit code floating around.

*nix fixed the problem a while ago, so it is a non-issue.

It clearly doesn't affect the 980 per information present IN THIS THREAD. It also doesn't affect my 290X, nor my TITAN.

Really, how you not choke to death on your own tongue?

Oh really?

and that's top of a list of a simple google search.

It is a problem with Windows which Microsoft will most likely fix with Windows 10 and pitch as an excuse to "upgrade".

The only reason that this problem has become apparent is because 4GiB+ cards are much more commonplace and people are trying to see if its actually *needed*.

That's an interesting read, but I don't think it's the exact same problem. No GTX 970 user has an issue seeing all 4GB VRAM, but using it is a different story. Most games that I have tested myself pretty much peak around 3.5GB VRAM usage (Gigabyte GTX 970 G1), although running a test like MSI Kombustor will bump VRAM usage higher a little, but nowhere near the 4GB equipped by the graphics card. When forced to use all the ram as per the image shown in the original post, performance drops off significantly.

It's not my image, but I have run the same test on my own GTX 970 and achieved similar results. It's just the only piece of evidence that I put up as it seems like a much more reliable test than multiple people reading VRAM usage from an OSD while gaming at a plethora of different configurations.

auxy wrote:

Really, how you not choke to death on your own tongue?

I don't want to get all R&P, but why do you have to be SO abrasive and attacking all the time?

FWIW, I believe Scott thinks (knows?) it's 32-bit executable thing. Maybe he can check into it to confirm. https://twitter.com/scottwasson/status/ ... 3022947329

auxy wrote:

It clearly doesn't affect the 980 per information present IN THIS THREAD. It also doesn't affect my 290X, nor my TITAN.

This, and this is why it's interesting.

The difference from the full GM204 to the one in the 970 is that the 970 has 3 of the 16 SMs disabled. The place where this fall-off occurs in the above images is at the 13/16th point so that might be a clue.

So (this is not my field but) are the GM204's 4 memory controllers attached 1 each to the 4 GPCs? And if so, what happens if (on some cards) the 3 disabled SM's are in 1 GPC?

The fact that this apparently bandwidth hit is in the high memory region might suggest it's a known hardware limitation and the firmware is aware of it and maps to ensure best performance.

auxy wrote:

Really, how you not choke to death on your own tongue?

Sometimes you make good, constructive comments and sometimes you make me facepalm. Have a guess which category today's quote fits into!

Topinio wrote:

The difference from the full GM204 to the one in the 970 is that the 970 has 3 of the 16 SMs disabled. The place where this fall-off occurs in the above images is at the 13/16th point so that might be a clue.

Does this affect the (only) other neutered Maxwell - the vanilla 750?

Krogoth wrote:

It is a known memory mapping problem with NT 6.x and earlier. It effects all GPUs with memory capacities greater than 4GiB. The OS were coded back when VRAM on GPU was less than 64MiB, so there's 32-bit code floating around.

*nix fixed the problem a while ago, so it is a non-issue.

What? It's not an operating system issue, as we would likely see similar results with all other 4GB video cards. Just looks like a weird bug in the firmware on 970's only, and I am sure they can patch it out with newer firmware or may be even drivers.

Perhaps the Op can test in a game and see if those are impacted in the real world? Increase the res or something between each run until 4K, which should defiantly be eating into that last 1GB. The performance drop between each res step should be somewhat linear in relation to the additional workload. If this theory is true, I would expect the card to suddenly drop off a cliff with memory bandwidth that low.

There's no other threads on the internet about this affecting anything in actual games (unless nobody has noticed)?

Well, I guess I'm just a hateful shrew. (´・ω・) Perhaps my early lifetime of physical and emotional abuse at the hands of my peers and resultant self-imposed splendid isolation, then my more recent computer support jobs, has left me with a surfeit of patience for other people's flaws! (Not that that excuses my behavior, but I wasn't trying to do that anyway. Nor would I! Merely answering the question posed to me.)

geekl33tgamer wrote:

Perhaps the Op can test in a game and see if those are impacted in the real world? Increase the res or something between each run until 4K, which should defiantly be eating into that last 1GB. The performance drop between each res step should be somewhat linear in relation to the additional workload. If this theory is true, I would expect the card to suddenly drop off a cliff with memory bandwidth that low.

There's no other threads on the internet about this affecting anything in actual games (unless nobody has noticed)?

There's a little thread on overclock.net about it. There, they tested some games and found it to affect actual games; mostly Skyrim and Shadow of Mordor it seems. Once RAM usage pushes past ~3.3GB, performance does drop off a cliff, with horrible stuttering.

Some people have misunderstood and thought the issue was that the card couldn't *access* all the VRAM and have subsequently "proved" it to not exist, but that's not the problem -- the problem is that the card can't access all VRAM at full speed, which means it's not going to be apparent unless you cross over the threshold, which most current games don't.

One more reason I'm glad I didn't pick up a 970! Really sucks for everyone that did, though! (/ω＼)

Chrispy_ wrote:

Does this affect the (only) other neutered Maxwell - the vanilla 750?

Would be difficult to tell, I think! (Given the low-end nature of the part.) It's worth investigating, though, for sure. It seems like this Nai's Benchmark could probably show it, pretty easily.

DancinJack wrote:

FWIW, I believe Scott thinks (knows?) it's 32-bit executable thing. Maybe he can check into it to confirm. https://twitter.com/scottwasson/status/ ... 3022947329

Pot-kettle-black-etc, but kinda douchey behavior there on twitter, Damage!
^{That kinda thing is why I don't use twitter anymore, ahaha...}

auxy wrote:

It clearly doesn't affect the 980 per information present IN THIS THREAD. It also doesn't affect my 290X, nor my TITAN.

It sure does effect titan and 290X in windows. Just fire up Unigine Valley run a benchmark and look at the memory reported.

Deanjo wrote:

It sure does effect titan and 290X in windows. Just fire up Unigine Valley run a benchmark and look at the memory reported.

Deanjo's face:

This issue sounds similar to the 660's limitations. Typical NVidia mid-range crippling.

It could also be a bug with the silicon itself when it is trying to map texture data to areas of the memory space meant for SMM blocks that got disabled. It causing a massive performance hit as the rest of the silicon "appears" to be waiting on "disabled" blocks. If this is the case, then there's no firmware that can fix it outside of reducing the effective memory space to "good" SMM blocks.

auxy wrote:

There's a little thread on overclock.net about it. There, they tested some games and found it to affect actual games; mostly Skyrim and Shadow of Mordor it seems. Once RAM usage pushes past ~3.3GB, performance does drop off a cliff, with horrible stuttering.

Some people have misunderstood and thought the issue was that the card couldn't *access* all the VRAM and have subsequently "proved" it to not exist, but that's not the problem -- the problem is that the card can't access all VRAM at full speed, which means it's not going to be apparent unless you cross over the threshold, which most current games don't.

Took a while (31 pages!), but interesting read outside of those (as you say) arguing about this problem not actually existing. It's weird why it wasn't noticed in every single review of the card done out there, or by Nvidia themselves? It honestly sounds like they have accidently gimped something in the chip when culling some of those SMM units, and if it is - That doesn't sound like it may be software fixable if it's a physical problem?

Deanjo wrote:

It sure does effect titan and 290X in windows. Just fire up Unigine Valley run a benchmark and look at the memory reported.

I'm not even...

Chrispy_ wrote:

Does this affect the (only) other neutered Maxwell - the vanilla 750?

I thought that too, and was like "hey, I have one of those to test it". It only has 2GB VRAM though, so it's unlikely to have the issue? I could give it a try if anyone knows where that tool can be downloaded from in the OP (from a site not in German!)???

Is there a link to the opening post tool?

Ryu Connor wrote:

Is there a link to the opening post tool?

I think it's here: http://www.computerbase.de/forum/showth ... st16869351

There's what looks like a 32 and 64-bit Cuda DLL and a main EXE. I can't work out how to use it. For once, I wish something come with instructions!

Edit: It doesn't seem to do anything if you just run the EXE and leave those DLL's in the same folder as it.

I figured it out.

Nai's Tool: https://mega.co.nz/#!w9kXUZZQ!A0yXbLnK1 ... jlucYreppo

Required Library: https://mega.co.nz/#!Eh0GzT4D!Kjhqzljt- ... VNpUaVpN6U

Put these into the same folder.

Then just run rec.exe from a command prompt.

My 770 Kepler shows the same problem as the 970 Maxwell. I'll edit a picture into this post in a moment.



I'm guessing the full 4GB isn't shown due to the existing frame buffer and assets from the OS. This tool doesn't run in full screen exclusive mode. I have a Kepler 680M with 4GB I'll put up in a moment.

Hopefully we are past the 4GB confusion by now.

To recap: The OP didn't highlight any issue with addressing 4G. but the fact that the GX970 is suffering performance issues >3.2GB, while the 980 doesnt.

I dont think any game truly leverage >3GB today (its mostly texture cache) , so even if nvidia, in their drivers, limit the usage of the 970 to 3.2GB, nobody would be the wiser.

But, if anyone can prove that the GTX 970 is doing that, nvidia will be hit with a serious class action suit.

I tried testing my 680M 4GB Kepler and unfortunately Optimus totally screws up the results. So the 770 4GB Kepler is it.

Let me try running it through remote desktop instead. See if I can free up the frame buffer and assets from Windows.

Ah hah. Got it. This is a contention issue. My thought about full screen exclusive access being lacked was right.

Okay so:

1. The final 128MB doesn't show because the tool reserves that.
2. The remaining 384MB or so of memory is reserved by the DWM (Desktop Window Manager).

To run the benchmark correctly you must do so from a headless state. Do not use Remote Desktop to do this. It will attempt to run the benchmark on the remote desktop video adapter and that ends in a application crash. When run from a headless state the problem resolves itself.

Before (Above 4G Decoding Disabled):



After (Above 4G Decoding Disabled):

Ryu Connor wrote:

Ah hah. Got it. This is a contention issue. My thought about full screen exclusive access being lacked was right.

Okay so:

1. The final 128MB doesn't show because the tool reserves that.
2. The remaining 384MB or so of memory is reserved by the DWM (Desktop Window Manager).

Any idea why the 980's appear to work (edit: when the 970's don't) though?

Topinio wrote:

Ryu Connor wrote:

Ah hah. Got it. This is a contention issue. My thought about full screen exclusive access being lacked was right.

Okay so:

1. The final 128MB doesn't show because the tool reserves that.
2. The remaining 384MB or so of memory is reserved by the DWM (Desktop Window Manager).

Any idea why the 980's appear to work (edit: when the 970's don't) though?

No clue. I don't think the opening post created that image (let me know if I'm mistaken). Since I don't know the source it's hard to say what's going on there.

The most basic explanation is the 980 test was run headless and the 970 one wasn't.

I'm sure there might be other explanations. As always more headless results from 4GB Kepler and Maxwell cards would be a boon.

Ryu,

By chance what motherboard was the GTX 770 connected to for that test?

Asus X99 Deluxe Rev 1.03 Firmware: 1203

Someone asked about the results for a GTX 750 Ti, as those too, also use gimped Maxwell parts. These are results for a Galaxy low-profile GTX 750 Ti. (Don't judge me, this is going into an HTPC once I'm done with it, hence low-profile.)

EDIT: NOT HEADLESS, will do that in a sec.

Ryu Connor wrote:

Topinio wrote:

Ryu Connor wrote:

Ah hah. Got it. This is a contention issue. My thought about full screen exclusive access being lacked was right.

Okay so:

1. The final 128MB doesn't show because the tool reserves that.
2. The remaining 384MB or so of memory is reserved by the .

Any idea why the 980's appear to work (edit: when the 970's don't) though?

No clue. I don't think the opening post created that image (let me know if I'm mistaken). Since I don't know the source it's hard to say what's going on there.

The most basic explanation is the 980 test was run headless and the 970 one wasn't.

I'm sure there might be other explanations. As always more headless results from 4GB Kepler and Maxwell cards would be a boon.

The image in the OP was supposedly from someone that owned both a GTX 970 and 980. I've ran the test on my own desktop and achieved similar results:



Interestingly (and disappointingly) the test itself actually causes my driver to crash.

Ryu Connor wrote:

Ah hah. Got it. This is a contention issue. My thought about full screen exclusive access being lacked was right.

Okay so:

1. The final 128MB doesn't show because the tool reserves that.
2. The remaining 384MB or so of memory is reserved by the .

To run the benchmark correctly you must do so from a headless state. Do not use Remote Desktop to do this. It will attempt to run the benchmark on the remote desktop video adapter and that ends in a application crash. When run from a headless state the problem resolves itself.

Before:



After:

I'm not sure how to run it in the same environment as yours, but I'm sure that even running it in a headless state wouldn't cause the performance decreases in the last ~700MB VRAM.

As for a "real world" test, I can't create data charts as eloquently as say, your average TR review, but here's a quick screenshot I took of Shadow of Mordor running at 1440p, everything maxed with the textures set to Ultra, which supposedly utilizes up to 6GB VRAM.



Statistics shown in the bottom right of the image, provided via MSI Afterburner and Rivatuner Statistics Server.

edit: resized image to fit