TR Forums

Ryu Connor wrote:

Asus X99 Deluxe Rev 1.03 Firmware: 1203

By chance do you have the 'Above 4G Decoding' option enabled in EFI? Would you be willing to test it again with it in the opposite state?

I had it disabled for the previous test results.

I just did a reboot and turned the setting on after your line of questioning made me think.

Headless Above 4G Encoding Enabled:


1024x768 Above 4G Decoding Enabled:


2560x1600 Above 4G Decoding Enabled:


The DWM scales in it's memory use and causes a contention issue with the rec benchmark. It must be done headlessly.

super.speler wrote:

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

There's a good chance that's because that section of memory it's testing is already in use.

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.

Unfortunately that sort of conflates things at the moment. Once you start using a game many other factors suddenly come into play to start impacting performance. I'm not saying you're not having a problem, but we gotta slice with a scalpel here.

I need you to run the rec benchmark with your monitor completely off & unplugged from the card and post those results.

Ryu Connor wrote:

super.speler wrote:

I need you to run the rec benchmark with your monitor completely off & unplugged from the card and post those results.

Wait. Is THAT all you need to make a Win 7 box headless? Disconnect all the displays? SHEESH, and here I am off in a corner trying to bash together a script that restarts, disables DWM, and outputs to a file...

BearBearBear wrote:

Ryu Connor wrote:

super.speler wrote:

I need you to run the rec benchmark with your monitor completely off/unplugged from the card and post those results.

Wait. Is THAT all you need to make a Win 7 box headless? Disconnect all the displays? SHEESH, and here I am off in a corner trying to bash together a script that restarts, disables DWM, and outputs to a file...

Yeah, I'm connected to a Dell 3008WFP via DisplayPort 1.1. I just cut off the monitor and that got the job done, entire memory range output proper values.

Windows 8.1 spits out the disconnected hardware/connecting hardware noise when I turn the monitor on and off. I'd still disconnect the monitor cable just to be sure.

Ryu Connor wrote:

Yeah, I'm connected to a Dell 3008WFP via DisplayPort 1.1. I just cut off the monitor and that got the job done, entire memory range output proper values.

Windows 8.1 spits out the disconnected hardware/connecting hardware noise when I turn the monitor on and off. I'd still disconnect the monitor cable just to be sure.

....that's not what I read about DWM. Wikipedia says that it's always on in 8 and can't be disabled.

Regardless, 750 Ti results, run without monitor plugged in:



So it looks like any existing issues are entirely within the 970, if it's not a contention issue outright.

BearBearBear wrote:

....that's not what I read about DWM. Wikipedia says that it's always on in 8 and can't be disabled.

I guess it could be true that 8.1 never cuts DWM off - it doesn't have a classic type mode like Vista and 7 did - but it might still properly release the frame buffer and assets so long as the monitor is disconnected.

Thanks for the additional results.

On Win 8 the DWM service was changed to be system critical -- meaning the machine will restart if it stops running -- but it likely will scale back it's memory usage if there's no display. Probably Windows Server logic to save RAM on all those headless machines.

I decided to build a simple script and execute this program in the background while running a game that would have full screen exclusive access.

Bioshock Infinite was at 1096MB in use according to Afterburner as I waited for the script to execute.

When the script kicked off after a two minute delay it stalled the entire graphic pipeline (no shock there). It also caused Afterburner to erroneously report that memory usage was 4094MB.

The result from the benchmark were totally trashed:



I was hoping it might illuminate if the Windows DWM retained any portion of video memory while a full screen exclusive game was running (I suspect it probably does). Unfortunately it doesn't look like my test idea can show that. Need a more robust tool, something like RAMMap except for GPUs.

I hypothesize that any application that pushes into the final 500MB of a video card - based on desktop resolution and regardless of total VRAM size - will cause memory pressures on DWM and force PCIe texture swaps and maybe even pagefile usage. This behavior should occur on AMD, Intel, and NVIDIA. Said scenario would explain the tanked performance.

I also presume that 4K or greater displays would have even more VRAM than the final 500MB reserved. One because that's how a framebuffer works and two because of earlier test pictures in this thread showing 1024x768 vs 2560x1600 and difference in vram consumption of the two.

This feels like a return of video cards in the 1990s: we had to make sure we had enough vram to run the resolution, color depth, and refresh rate of our monitors. There appear to be a few niche games on the market that are pushing boundaries and 4GB ain't getting it done.

Why are you investigating some kind of DWM thing?

The benchmark is supposed to be run from the IGP, with nothing connected to or running on the NVIDIA GPU.

I think the theory about disabled SMMs seems much more likely than any Windows issue.

Ah, nevermind. I read the thread again and understood you were investigating this as a secondary curiosity. Carry on, carry on! ('ω')ノ

I'm surprised that nobody has attempt to perform this on *nix to eliminate any possibility that it is OS-related.

Krogoth wrote:

I'm surprised that nobody has attempt to perform this on *nix to eliminate any possibility that it is OS-related.

Even in UNIX, you still need memory for the framebuffer alone.

Windows Server 2012 has a no-GUI install option. Why not just do a free install of it and run the test again since it's command line anyway? If I had a 970 I'd do that right now as I'm really curious.

Kougar wrote:

Windows Server 2012 has a no-GUI install option. Why not just do a free install of it and run the test again since it's command line anyway? If I had a 970 I'd do that right now as I'm really curious.

Server 2008 has it too, it's called Server Core.

It still has a frame buffer if you connect to it locally as it still does a graphical output of a background and shell.

morphine wrote:

Krogoth wrote:

I'm surprised that nobody has attempt to perform this on *nix to eliminate any possibility that it is OS-related.

Even in UNIX, you still need memory for the framebuffer alone.

It can still be a problem with memory mapping and Windows. That's why running tests in other environments will help to ascertain this or not. This is starting to feel like the whole x86 to x86-64 transition again.

Krogoth wrote:

I'm surprised that nobody has attempt to perform this on *nix to eliminate any possibility that it is OS-related.

Is there any source code? I tried following the link but only found windows binaries.

cobalt wrote:

Krogoth wrote:

I'm surprised that nobody has attempt to perform this on *nix to eliminate any possibility that it is OS-related.

Is there any source code? I tried following the link but only found windows binaries.

http://forums.guru3d.com/showpost.php?p ... tcount=115

You can find the source there.

Albeit the associated library is a .dll and not a lib.so - I presume that's gonna pose a problem.

Krogoth wrote:

I'm surprised that nobody has attempt to perform this on *nix to eliminate any possibility that it is OS-related.

I'm game.



I just installed some of the OpenGL developer tools that'll report VRAM usage. And here is the result:



To hit the VRAM limit, I cheated: I started running multiple games until I hit the limit. The drop you see in the graph when it hits 4 GB is OS X removing one of the game's allocation to main memory make room for another title.

EDIT: I probably should add that this was done with nVidia's 343.02.01f01 driver, not Apple's OEM driver that comes stock with OS X 10.10.1.

Krogoth wrote:

It can still be a problem with memory mapping and Windows. That's why running tests in other environments will help to ascertain this or not. This is starting to feel like the whole x86 to x86-64 transition again.

Look, you will never ever be able to manually allocate *all* of the GPU memory without a performance drop in the last section... because you need somewhere to store the frame buffer and if it gets swapped out to main RAM via PCIe you will see a slowdown .

For testing if there's an actual problem (hint: there isn't), the testing app in question needs to ascertain how much VRAM Windows is using for Aero, framebuffers, etc, and only allocate the remainder, so that we get a nice even 4GB or whatever the amount is.

morphine wrote:

Look, you will never ever be able to manually allocate *all* of the GPU memory without a performance drop in the last section... For testing if there's an actual problem (hint: there isn't)

What about the results that DON'T show a performance drop in the last section?

the testing app in question needs to ascertain how much VRAM Windows is using for Aero, framebuffers, etc, and only allocate the remainder, so that we get a nice even 4GB or whatever the amount is.

If you run it on IGP, no dGPU VRAM is used.

ExtremeTech have an article on the problem now, worth a look:
http://www.extremetech.com/extreme/198214-198214

So does TR, complete with comments from Nvidia:

http://techreport.com/news/27721/nvidia ... tion-issue

auxy wrote:

What about the results that DON'T show a performance drop in the last section?

That shows that this is likely a driver issue, no more.

Putting this in perspective: what's annoying me is the apparent misuse of a software tool, and a TON of jumping-to-conclusions, esp. regarding the hardware being broken somehow. The number of backseat coders / software & hardware engineers coming out of the woodwork to misinformedly talk about this issue is Too Damn High [insert même here]. Should it be looked into? Sure. Should we start going "zoinks 970 b0rk3n!"? Heck no.

auxy wrote:

If you run it on IGP, no dGPU VRAM is used.

Almost, if it's on and showing a picture, it's using something. Heck, Win might have initialized just in case (which would make sense).

auxy wrote:

What about the results that DON'T show a performance drop in the last section?

That's the hitch. If you run this test incorrectly you can make every card regardless of vram configuration and size show a performance drop in the last section due to contention with the framebuffer and assets of the OS. If the test isn't being done right it makes the situation really hard to get a grasp on.

This is why earlier in this thread I mentioned we needed to slice with a scalpel. Have to execute the test correctly first and then we'd be in a better position to see the real problem.

If you run it on IGP, no dGPU VRAM is used.

Just unplugging the monitor works just as well - especially given that not everyone has an IGP.

Just FYI, the reason I suggested the 750 Vanilla (not the Ti) is because it is neutered Maxwell. Only the 970 and the 750 are chopped parts, the 980, 960 and 750Ti are fully-enabled parts.

The neutered 750 Vanilla might exhibit issues that the 750Ti does not, just like the neutered 970 exhibits the issue but the 980 does not.
The 750 is 4/5ths of 750Ti
The 970 is 13/16ths of a 980

Chrispy_ wrote:

Just FYI, the reason I suggested the 750 Vanilla (not the Ti) is because it is neutered Maxwell. Only the 970 and the 750 are chopped parts, the 980, 960 and 750Ti are fully-enabled parts.

The neutered 750 Vanilla might exhibit issues that the 750Ti does not, just like the neutered 970 exhibits the issue but the 980 does not.
The 750 is 4/5ths of 750Ti
The 970 is 13/16ths of a 980

I had to go look that up. Thought vanilla 750 was a Kepler part and 750 Ti was the cut-down Maxwell. You can tell I'm usually Team Red for these kinds of things.

You're not entirely to blame, because Nvidia is playing re-badge shenanigans as usual - The 750M is Kepler. Nvidia released mobile Maxwell with the 860M, but there are both Maxwell and Kepler 860M variants which is a practice I find dirty; They flood reviewers with the sexy, new, and power-efficient Maxwell variants that are almost impossible to actually buy whilst clearing inventories of their outdated inefficient chips to people who aren't aware of this filty scam. I'm not entirely sure how it's legal but I guess it's buried on page 406 of the smallprint legalese disclaimer.

The 750 and 750Ti on desktop avoid all this silliness at least; Both are GM207 and the Ti is uncut.

I have access to a 750 non-ti 1GB GDDR5 (in a Sandy Bridge Pentium with a single DIMM running Win7). If you tell me what to run & where to get it I can do some testing.

I don't think it should be a problem that it's only a 1GB card; AFAIK they use the same number of lower capacity chips to get the same bandwidth, so I'd expect to see any issues in the same proportion of the memory.

Melvar wrote:

I have access to a 750 non-ti 1GB GDDR5 (in a Sandy Bridge Pentium with a single DIMM running Win7). If you tell me what to run & where to get it I can do some testing.

Sorry, I couldn't help myself. Carry on.

Any individuals engaging in testing are also encouraged to look here for inspirational music.

Melvar wrote:

I have access to a 750 non-ti 1GB GDDR5 (in a Sandy Bridge Pentium with a single DIMM running Win7). If you tell me what to run & where to get it I can do some testing.

I don't think it should be a problem that it's only a 1GB card; AFAIK they use the same number of lower capacity chips to get the same bandwidth, so I'd expect to see any issues in the same proportion of the memory.

viewtopic.php?p=1233880#p1233880

Download the files listed in that post. Once you have rec.exe and the cudart64_65.dll beside one another you simply need to run the command from a command prompt.

When you run the benchmark it must be done with the monitor unplugged from the graphics card.

Otherwise it will give bad results.