Ich hoffe Dir langt ein Screenshot, denn leider zeigt der Resourcenmonitor nicht den VRAM-Verbrauch an, was aber GPU-Z leisten kann.
Dieses Bild ist direkt nach dem Raustabben aus Skyrim entstanden.
Ich habe GPU-Z mitprotokollieren lassen:
Nachstehend die wichtigsten Zeiten (Das die Zeiten stimmen, kannst Du an der Systemuhr auf den ersten Screenshot verifizieren):
1. Vor dem Starten von Skyrim und beim Start:
2. Beim laufen von Skyrim:
Wie gut zu sehen ist, verbraucht Skyrim 2.838.392 kByte was 2,697 GByte entspricht. Der Zuwachs an Grafikspeicher beträgt 1.986 MByte was 1,939 GByte entspricht (siehe Screenshots)
Das macht zusammen 4,636 Gbyte, was die Grenze von 4 GByte locker überschreitet.
Ich habe hier alle Effekte im NvidiaInspector ausgeschaltet um Ungenauigkeiten zu vermeiden und Skyrim nicht an die Grenze des Absturzes zu bringen.
Die Max-Grenze an Arbeitsspeicher ist für eine 32Bit Anwendung auf einem 32Bit Windows = 3 Gbyte mit gesetzen
IMAGE_FILE_LARGE_ADDRESS_AWARE and 4GT ansonsten 2 GByte (Quelle: Memory Limits for Windows Releases:
http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx#memory_limits )
Bei einem 64bit Windows verschiebt sich das ganze auf 4 GByte.
Warum Skyrim selbst auf einem 64bit Windows schon bei 3,1 GByte aussteigt, kann eigentlich nur noch an der Engine liegen.
Was Du über den virtuellen Arbeitsspeicher schreibst/zitierst, stützt doch die Theorie, das die Texturen im Arbeitsspeicher abgelegt werden.
Übrigens zum Thema Grafikspeicher und der Verwaltung des selben:
http://de.wikipedia.org/wiki/Grafikspeicher
Hier möchte ich besonders auf diese Passage hinweisen:
Flaschenhals Systembus
Ältere Grafikkarten geben Grafikberechnungen an die CPU ab. Durch höhere Auflösungen und mehr darstellbare Farben wuchs im Laufe der Zeit der Datenstrom zwischen GPU und CPU immer weiter an bis er durch die Leistungsfähigkeit des Systembusses ausgebremst wurde. Ein weiteres Problem war der benutzte Grafikspeicher. Dieser erlaubt keine gleichzeitigen Lese- und Schreibzugriffe. Der
RAMDAC muss mit dem Auslesen warten, solange die CPU in den Speicher schreibt und umgekehrt. Auf modernen Computern ist der Systembus die kritische leistungsbestimmende Komponente; das zeigt sich insbesondere bei aktueller 3D-Grafik. Die folgende Beispielrechnung soll dies verdeutlichen.
- Darstellung einer Szene in der Auflösung 1280 × 1024 Pixel mit 32 Bit Farbtiefe und 50 Bilder pro Sekunde
1280 × 1024 × 32 Bit × 50 1/s = 2097,152 MBit/s Diese ca. 2100 MBit pro Sekunde berücksichtigen nur den zur Monitorausgabe nötigen Datenstrom. Die gesamte eventuell anfallende Datenübertragung zur Bildsynthese trägt zu dem Wert nichts bei. Als Konsequenz daraus sollte die Nutzung des Systembusses auf ein Minimum verringert werden.
- Alle zur Bildsynthese oder -ausgabe anfallenden Berechnungen werden von einer separaten und lokal von der CPU getrennten GPU vorgenommen.
- Die GPU verfügt über eigenen und direkt erreichbaren Halbleiterspeicher. Die möglichst seltene Nutzung des Hauptspeicher sollte nur dann erfolgen, wenn der lokale Speicher nicht ausreicht.
- Als verwendeter Halbleiterspeicher sollte kein normaler DRAM verbaut werden, da dieser den hohen Anforderungen der GPU nicht genügt. So erlaubt DRAM zum Beispiel keine gleichzeitigen Lese- und Schreiboperationen. Das ist für eine Grafikkarte wichtig, da der RAMDAC kontinuierlich Teile des Speichers ausliest während die GPU Ergebnisse in den Speicher schreibt.
Sollte das VRAM der Grafikkarte wirkllich in den bestehenden Arbeitsspeicher eingerechnet werden, dann wäre dieses hier unmöglich:
http://www.3dmark.com/3dm11/5979015
Den hier müsste Windows 7 schon beim booten abstürzen, da es 6 GByte VRAM in einen Adressraum von 4 GByte RAM einbinden soll.
Hier zum Vergleich die Ergebnisse meines Systems:
http://www.3dmark.com/3dm11/6890669
