Well, I hope this is the right place to discuss a disagreement between me and the author (Igor ...):
You've stated that the graphics devices' memory isn't copied to the system memory, but I learned otherwise from my 3D programming experience. Let's agree on a few things, shall we?
■Available memory adresses (all 2^(16/32/64) off 'em) are distributed to any memory areas that need a system wide calling name. This will mostly be VRAM and RAM, with some minor stuff like PCI and the BIOS settings chips begging for them.
■The above is
the reason for the unability to use more than around 3.5GiB (yes, the real exponential ones) of the 4GiB of available pointers: your CPU, limited by the OS or any other way around has run out of names (pointers) to call them. No adress space is left. The names that would we distributed to RAM is used by other more important parts like VRAM and BIOS. The only partial solution is PAE, which ups the limit of virtual space to 2^36 (64GiB).
■Graphics card memory is used for vertex- and index buffers, together with textures, tesselation buffers, pre-ROP-frames (waiting for AA for example) and one post-ROP-frame (when using the DISCARD swap effect, quite a common one, even the required one for any AA type). And a few Effect Files too.
If that's correct, please explain to me why this is 'wrong' then:
■Assigning the storage flag 'D3DPOOL_MANAGED' (quite a common one, even the usual one) to device::CreateSomeMemoryEatingResource() first moves the resource to RAM and automatically moves the resource to VRAM when it's being used with stuff like SetTexture() or DrawIndexedPrimitive() for speedy access by the GPU.
■A copy of these resources is kept in system memory (when using that flag) as a backup. Should the device loose track of what it's doing due to losing focus or any other spooky reason (and fail to recover it's VRAM) the backup will be copied back to VRAM.
At least, that's what I learned from real lessons, books like 'Introduction to 3D Game Programming with Direct X 9.0c: A Shader Approach' and online tutorials. I hope you'll be able to clarify all about this.
-------------------------------------------------------
And for the other discussion about what's enough to disable the page file: I've been using 2GiB + 1GiB disk (yes, DDR3 was expensive back then, about €30/GiB) ever since okt. 2009, played the toughest games like Crysis, Prototype, FSX and Dragon Age and even did quite a lot of rendering using Mental Ray in 3dsMax drawing up to a milion faces in the viewport, and I never ever encountered any problems with crashing when thinking properly about memory usage of the renderer. Of course it isn't hard to make 3dsMax crash with some overkill smoothing, but that's not what we're talking about. A.t.m. (excluding chrome) 32 processes are running (wireless and the printer still work
) and Windows itself uses about 400MiB of memory. So yes, I've you're a diehard tweaker, even 4GiB will be enough.
tom thumb :
I like the idea of a ram disk, but isn't that a waste of ram? Wouldn't you also run into a ton of compatibility problems? Doesn't the ram physically forget everything after shutdown? I don't get it.
It is indeed a waste if you've got a 64bit Windows lying around somewhere and don't hesitate to upgrade.
But the point of it is that with PAE you can use up to 2^36 bytes of RAM (64GiB) as
virtual memory. That means that the page file can be as huge as 64GiB. But the old fashioned page file is stored on the HDD, which is damned slow compared to RAM (more than 100x as slow using sequential tests and in my case 318181x (14ms/44ns) slower when comparing access time). This way, you can store that page file (with its almost unlimited size) on RAM.
And yes, as any capacitor-based memory does, your data goes up in [strike]smoke[/strike] electrons when power is cut off.