Turbocache/Hypermemory/Shared Memory > Invisible Memory

[vbcrayon]

Today most cards have this "technology". They take X amount of memory, regardless of OS (x64 or x86). Formerly these
instructions were controlled by the driver and easily disabled.
http://howtotroubleshoot.blogspot.com.b ... cache.html
With Windows 7, the system controls this function (Shared Memory) and to my knowledge, there is no hack to disable.
http://msdn.microsoft.com/en-us/windows ... 87348.aspx
And this:

@TriLLi, the memory that you see allocated in DirectX is not memory that gets directly and irrevocably allocated to the graphics card but is in fact the amount of memory that the system has available to share with the graphics card if needed, it is different to TurboCache where (I believe) memory is reserved and blocked against other use. The shared memory is still managed and used by the system and only gets allocated when the graphics card actually needs it

FancyCache Cache Memory (including and especially Invisible Memory for x86), what makes these cases? If the system needs memory for the video card that was already "reserved", what can happen? A BSOD?

If in doubt check: "Control Panel\All Control Panel Items\Display\Screen Resolution" and click "Advanced Settings".

Edit:

So I have read the whitepaper and your earlier post on the subject (I wish I had found that at the start of my investigation, very nicely put!) it seems that Microsoft have issued the following explanation for how these values are reached:

TotalSystemMemoryAvailableForGraphics =
MAX((TotalSystemMemory - 512) / 2), 64MB)

As well as for the shared memory:

MaxSharedSystemMemory = TotalSystemMemoryAvailableForGraphics - DedicatedSystemMemory

SharedSystemMemory = MIN(MIN(SumOfCommitLimitOnAllApertureSegment, DXGK_DRIVERCAPS.ApertureSegmentCommitLimit), MaxSharedSystemMemory)

The eagle eyed amongst us will notice they have their brackets wrong - silly Microsoft.

What I primarily noticed is that in the whitepaper it didn't explain these calculations or the origins of the integers used in the 'TotalSystemMemoryAvailableForGraphics' calculation. Having tried these calculations in the various ways I can see that they could be interpreted with several of the systems I have access to I cannot seem to get the results to match what is happening in practice.

Example:

The machine I write this on has

8192mb of system memory
4095mb Total available graphics memory
758mb Dedicated video memory
0mb system video memory
3327mb shared system memory


If I calculate MAX(((8192 - 512) / 2), 64)

= MAX((7680 / 2), 64)
= MAX(3840, 64)
= 3840

Therefore:

TotalSystemMemoryAvailableForGraphics = 3840mb

This figure is clearly at odds with what is being reported!

Although fascinating this also hasn't got me any closer to being able to control these settings so any suggestions towards that end would be greatly appreciated.

http://www.sevenforums.com/tutorials/89 ... guide.html

[Mradr]

I think you have it a bit wrong. There are two memory listing for ram:
1) The mother board is what tells the OS how much ram is usable to the system. This is why some MB can only support up to 32GB of ram and others up to 128GB. No matter what, even with their invisible memory solution, you can't go past the limit of the mother board.

2) The os is what actully maps the memory so the system can use the memory. The system maps the memory off the bit it can ready and use... henc 32bit and 64bit. Now. x86 was a bit misleading telling users that it can only support 32bit. In real life, x86 was a hybrid of a 64bit and a 32bit os. Microsoft wanting to keep things simple made x86 stand for 32bit memory size only and other limits within the software so programers at the time didn't make to many mistakes (what we call standers).

From what I am getting from your post is that you think opening up the unused ram would cause a crash as the system will use the ram where the OS would've said that is safe yes? Well no, the os is smart enough to know where to place files within its own memory map. The OS actulyl does see all the ram it can use from the MB like I said above, but it can only use about 3.5GB for programs only. Anything that goes outside of this memory map isn't use for programs, but for devices only instead. You can think of this as having 3.5GB programs and MB limit for devices.

Because FC is a driver base program, it can ask the OS to use that unused memory for a fack device allowing it to have that unused memory because the OS will know about it and make changes as needed.

What this means is this:
MB = holds 16GB of ram with only 8GB of ram in use.
OS is 32 bit, but the MB/BIOS tells the OS there is 8GB of useable ram and the OS will give it addressing for the 8GB of ram and another 8GB of unaddressed memory.
OS tells users that 3.5GB is usable for programs, the rest of the 4.5 is free for driver use.
The GPU says it will need 1GB worth of that ram for it self to do addressing/m-maping. The OS tells the bios and the bios/OS kows there is still 8GB of free memory addressing left for use. The GPU will use the unaddressed memory instead of the 4.5Gb that was taken up by the RAM addressing. Instead, if the gpu runs out of memory, will then start to use the program ram to help data loading witch is slow, but still faster than loading from the hard drive.

I might have covered what you wanted to hear, or maybe even said it simple enough, or that it could be hard to read, but to answer your question, no it will not cause a BSOD.