Jump to content

Fix for Windows 8/10 VRAM cap incoming?


Nebulous112

Recommended Posts

I still fail to see how this is a "bug" when that's just how 32 bit addressing works, but if the placebo makes people happy....

Link to comment
Share on other sites

17 hours ago, Arthmoor said:

I still fail to see how this is a "bug" when that's just how 32 bit addressing works, but if the placebo makes people happy....

 

16 hours ago, lmstearn said:

Each Windows 32bit app has its own pool of 4Gb. To extend it they must be dusting off the cobwebs from the old Win 16 viz expanded memory codebank of tricks. :P

This bug has nothing to do with the ~3.1GB of RAM that a 32-bit application can use.

 

This bug restricts the VRAM available to DX9 applications to 4GB. This includes any virtual RAM allocated to be shared with the GPU (per ENB/ENBoost).

The bug can be confirmed by running Boris' VRAMSizeTest Tool. http://enbdev.com/download_vramsizetest.htm

On Windows 8/10, the maximum value is 4064MB for DX9 (this is VRAM + shared virtual RAM). On Windows 7, this arbitrary maximum value does not exist - the value will show whatever is actually available on your computer.

 

From the DirectX dev in the linked Reddit thread:

"Hey guys, sorry this took so long to get taken care of. I was being honest when I said this was the first I heard of the issue - I've been on the DirectX team for over 5 years (joined at the end of Win8 development) and had no idea about this problem, or I would've pushed to fix it sooner.

For what it's worth, the reason it broke and the reason it's not simply trivial to fix is because there's an API available in D3D9 which is completely broken if we allow more than 4GB to be used. Since this API can only return a limit of 4GB, we had to rationalize what it means to be able to allocate more than that. In the Win8 timeframe, the rationalization was that it didn't make sense and 4GB should be a hard limit in D3D9 - which was apparently the wrong answer, since at least some apps depended on more than that. Hopefully we get it right this time.

I wish I could get the fix to you sooner, but it's got a lot of validation to go through before it makes it to the insider fast ring. I had no idea there were this many people clamoring for a fix, so seeing this makes me glad that I started reaching out."

Link to comment
Share on other sites

 

19 hours ago, lmstearn said:

Each Windows 32bit app has its own pool of 4Gb. To extend it they must be dusting off the cobwebs from the old Win 16 viz expanded memory codebank of tricks. :P

Wow, the memories...

However, PAE has been around since over two decades. https://en.wikipedia.org/wiki/Physical_Address_Extension

But GPUs do their own addressing anyhow. And then there is "Video Memory", which is a combination of VRAM and RAM offered by DirectX/OS.

In any case, 32/64 bit refers to CPUs main registers and not memory address width.

 

Link to comment
Share on other sites

4 hours ago, Sheson said:

 

Wow, the memories...

However, PAE has been around since over two decades. https://en.wikipedia.org/wiki/Physical_Address_Extension

But GPUs do their own addressing anyhow.

 

There's the rub, a fine addressing system and all that memory gone to waste because no-one could use it! Until recently perhaps. Yay. :)

 

Quote

 

And then there is "Video Memory", which is a combination of VRAM and RAM offered by DirectX/OS.

In any case, 32/64 bit refers to CPUs main registers and not memory address width.

 

Interesting, never got around to perusing the DirectX SDK, so don't know much about it. And then looking at the set of functions in the DirectX NVAPI Interface it's not at all obvious where any actual memory blocks actually get shuffled around. :P 

Link to comment
Share on other sites

  • 4 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...