VRAM Allocator CUDA-Version

HisN

Fleet Admiral
Registriert
Nov. 2005
Beiträge
83.287
Die Diskussion wie viel VRAM man nun wirklich auf einer Grafikkarte braucht ist so alt wie das Forum, wenn nicht sogar älter :-)
Bis jetzt konnte man die Frage nur schwer beantworten, z.b. indem man "gleiche" Grafikkarten mit unterschiedlicher Speicher-Ausstattung gegeneinander geprüft hat.
Aber damit konnte man nicht "jede" Speichermenge simulieren, und ständig Karten umstecken ist an sich auch nicht der richtige Weg.

Hier kommt der User @ZeroStrat ins Spiel.
Er hat mal schnell ein kleines Programm geschrieben, das über Cuda eine beliebige VRAM-Menge belegt.
Man kann also jetzt den Speicher einer Grafikkarte bewusst "begrenzen" indem man einfach Teile davon füllt.
Und schon kann man ganz genau erkennen ab wann eine Software anfängt an Leistung zu verlieren wenn ihr der Speicher ausgeht.
Und das ohne Karten tauschen zu müssen, einfach mit ein paar Zeilen in der Eingabe-Aufforderung.

Download-Link: https://1drv.ms/u/s!As_jnW8h38YpgcZ0wUsAP7tNmnFf1Q

Aufruf des Tools über die Konsole:
Code:
gpumem.exe 1000

1000 sind 1GB. Quellcode ist auch im Ordner und wird mit
Code:
nvcc gpumem.cu -o gpumem -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin"

kompiliert, falls man das selbst kompilieren möchte. Dazu braucht man noch das CUDA SDK: CUDA Toolkit 10.1 Download | NVIDIA Developer

Hier als Beispiel. Ich habe im Leerlauf gut 1GB VRAM der Graka mit dem Zeug was bei mir so am Desktop läuft durch den Fenstermanager belegt.
Leerlauf.jpg


Ich starte das Programm mit dem Wert 10 GB und es werden 10GB VRAM gefüllt.
VRAM-Gefuellt.jpg


Und sobald ich Return drücke, geht es auf den alten Wert zurück.
VRAM.Fertig.jpg


So kann man jede Software dazu zwingen mit dem Speicher jonglieren zu müssen und genau sehen ab wann welche Software bei welchen Settings anfängt zu stottern oder die FPS in den Keller gehen. Und zwar ohne viel Aufwand.

Ich hofffe das hilft bei der Frage: Wie viel VRAM ist wirklich nötig. Auch wenn die Beobachtung zur Zeit tatsächlich nur auf Grafikkarten mit "mehr als Genug" VRAM Punkte bringt, weil man auf Grafikkarten die sowieso schon zu wenig VRAM haben nur den Memorymanager mit Swappen beschäftigt. Wobei man allerdings aus der Beobachtung wie viel nun tatsächlich ins RAM geswappt wird, AUCH seine Schlüsse ziehen kann..

Vielen Dank nochmal an den Programmierer @ZeroStrat
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Haldi, r4yn3, Nero1 und eine weitere Person
Sehr cool, dann kann man bei den VRAM Diskussionen endlich mal Fakten liefern. :D
 
Genau das war auch mein Gedanke. Aber da ich ja eine völlige NIETE in Sachen Programmierung bin ... musste erst ein gaussmath her :-)
 
@HisN Ist bei diesen Verfahren sichergestellt, dass der vom Testprogramm "gpumen" belegte VRAM nicht per Swapping in den System RAM ausgelagert wird?
 
Erster Test, weil es gerade woanders um "reichen 6GB VRAM" geht.

ROTTR in DX11 mit VXAO (kein AA/SSAA/DSR) rest Maxed-Out in FHD.

ROTTR_2019_03_03_16_31_30_317.jpg

Ich starte das Tool und reduziere die VRAM-Menge um 18GB, so das nur 6GB für mein System übrig bleiben.
ROTTR_VRAM-Knapp.jpg


Das Ergebnis darf zu denken geben. Man sieht genau was mit den FPS passiert und wie das fehlende VRAM vom System kompensiert wird.
ROTTR_2019_03_03_16_34_18_843.jpg

Und noch schnell der Gegentest mit nur 10GB geklautem Speicher. Nicht das jemand erzählt, es wäre das Tool, das die Rechenzeit beansprucht.
ROTTR_2019_03_03_16_46_25_605.jpg

Und das beste an der ganzen Sache: es funktioniert sogar im CPU-Limit^^

Hallo32 schrieb:
@HisN Ist bei diesen Verfahren sichergestellt, dass der vom Testprogramm "gpumen" belegte VRAM nicht per Swapping in den System RAM ausgelagert wird?

Ich würde sagen, das belegen meine Screenshots, die ich gerade gemacht habe. Schau auf mein RAM-Bedarf. Du darfst aber auch gerne den Programmierer direkt fragen ...

http://extreme.pcgameshardware.de/grafikkarten/533786-vram-allocator-cuda-version.html

Der ist dort aktiv und bastelt gerade an einer CL-Version, damit die AMD-User auch was von dieser Software haben.
 
  • Gefällt mir
Reaktionen: s1984
Ich bin übrigens auch hier (gaussmath)... ^^ Swapping-Probleme sehe ich keine. An HisNs Screenshots sieht man's ja auch. Zur Not baue ich das halt um.
 
Zuletzt bearbeitet von einem Moderator:
Oh bitte so lassen. Es soll ja zeigen was das System macht. Und es macht genau das was es soll.
Es lagert Daten die nicht ins VRAM passen ins RAM aus. Also das, was das System auch macht wenn das Tool nicht laufen würde, und zu wenig VRAM vorhanden ist.
 
  • Gefällt mir
Reaktionen: ZeroStrat
Das Tool verursacht keine Auslastung auf der GPU. Es wird nur Speicher reserviert.
 
Hier der OpenCL Code für AMD Grafikkarten:
C:
#include <stdio.h>
#include <OpenCL/opencl.h>

int main(int argc, char *argv[])
{
     unsigned long long mem_size = 0;
     int err; // error code
     cl_device_id device_id; // compute device id
     cl_context context; // compute context
     cl_mem devTestMem
   
     err = clGetDeviceIDs(NULL, CL_DEVICE_TYPE_GPU, 1, &device_id, NULL);

     if (err != CL_SUCCESS)
     {
         printf("Error: Failed to create a device group!\n");
         return EXIT_FAILURE;
     }
   
     context = clCreateContext(0, 1, &device_id, NULL, NULL, &err);

     if (!context)
     {
         printf("Error: Failed to create a compute context!\n");
         return EXIT_FAILURE;
     }

     // get amount of memory to allocate in MB, default to 256
     if(argc < 2 || sscanf(argv[1], " %llu", &mem_size) != 1) {
        mem_size = 256;
     }
     mem_size *= 1024*1024;; // convert MB to bytes

     // allocate GPU memory
     devTestMem = clCreateBuffer(context,CL_MEM_READ_WRITE,mem_size,NULL,&err);
   
     if(!devTestMem) {
        printf("Error, could not allocate %llu bytes.\n", mem_size);
        return EXIT_FAILURE;
     }

     // wait for a key press
     printf("Press return to exit...\n");
     getchar();

     // free GPU memory and exit
     clReleaseMemObject(devTempMem);
     clReleaseContext(context);
     return 0;
}

Muss das jetzt nur noch kompilieren...
 
  • Gefällt mir
Reaktionen: Yogi666, Haldi, thuNDa und eine weitere Person
Sehr schön, großes Lob für die Arbeit. Sowas wünsche ich mir schon lange.

Ich hoffe das Tool kommt auch bei offiziellen Reviews mal zum Einsatz und es werden Tests ähnlich den Skalierungstests mit CPU Kernen erstellt.

Hut ab.
 
50 Zeilen Code? Krass .. und darauf warte ich seit 10 Jahren. Du bist heute mein Held @ZeroStrat.
Solltest Du mal in Berlin sein ... Bier oder Tee .. ist mir egal. Du bist eingeladen.
 
  • Gefällt mir
Reaktionen: Haldi und ZeroStrat
Dauert noch ein wenig mit dem OpenCL Pendant. Ich gehe den umständlichen Weg übers Visual Studio, weil ich das eh mal einrichten wollte.
 
Sehr nett. Wird der VRAM auch wirklich fest reserviert oder hätte der Grafiktreiber die Möglichkeit, den reservierten Speicher irgendwie wieder auszulagern, wenns knapp wird?
Denn wenn sich das Tool und das Spiel um den knappen Speicher streiten, kann ja auch das Tool den Kürzeren ziehen bzw. wenns ausgeglichen ist, müsste sowohl das Tool, als auch das Spiel auslagern...

Und das wäre ja kontraproduktiv, wenn einerseits der reservierte Speicher ausgelagert werden würde (dann hätte die zu testende Anwendung mehr Speicher zur Verfügung als gewollt) und andererseits würde die Speicherbandbreite zusätzlich belastet werden, wenn der Treiber versucht, den reservierten Speicher hin und her zu schaufeln. Sprich die Speicherbandbreite würde von zwei statt nur einer Anwendung beansprucht werden. Aber genau das soll ja NUR das Spiel machen.
Also muss der reservierte Speicher in jedem Fall fest sein und dürfte niemals ausgelagert werden.

Da ich dazu jetzt nix gelesen habe, frag ich vorsichtshalber einfach mal, ob das auch bedacht wurde bzw. ob das passieren kann. Aber da das das erste ist, was mir in den Sinn gekommen ist, würde ich mal vermuten und hoffen, dass das bereits berücksichtigt wurde. :p
Ergänzung ()

Okay, habs grade mal getestet bei meiner GTX980. 3350 MB waren grade das maximum, was ich einstellen konnte, weil Browser, Steam usw. noch liefen, der VRAM war dann bei 3,7 von 4 GB Auslastung.

Dann hab ich Shadow of the TombRaider gestartet. Dort habe ich die Settings nahezu auf maximum incl. der bestmöglichen Texturen, was sonst dafür sorgt, dass der VRAM komplett voll ist.
Trotz der zusätzlichen Belegung durch das Tool, zeigt sich das Spiel völlig unbeeindruckt.
Meine Karte schafft nach wie vor die mit diesen Settings üblichen ~40 FPS. An den Frametimes hat sich auch nix geändert, läuft auch ohne merkbare Ruckler oder Hänger.

Ein weiterer Blick auf den Taskmanager nach dem das Spiel beendet wurde zeigt dann auch, was passiert ist.
Der ganze reservierte Speicher wurde in den "Gemeinsamen GPU Speicher", also in den RAM ausgelagert und verbleibt dort nach beenden des Spiels auch. Die VRAM Auslastung war nach Beenden des Spiels bei ca. 1GB.

Tut mir leid, das sagen zu müssen, aber anscheinend erzielt das Tool nicht den gewünschten Effekt. :(
Der Grafiktreiber lagert den reservierten Speicher einfach aus, sobald das Spiel den VRAM voll macht. Und das Tool bemüht sich auch nicht, den Speicher wieder vollzumachen. Vermutlich, weil die Daten nicht aktiv fürs Rendering gebraucht werden, also interessiert sich der Grafiktreiber auch gar nicht mehr dafür und belässt die Daten ausgelagert.


Irgendwie hab ich aber auch meine Zweifel, dass eine "feste" Reservierung überhaupt möglich ist. Denn sonst könnte eine Anwendung ohne Weiteres einfach das komplette System abschießen. Man stelle sich vor, ich würde 4GB reservieren. Windows selbst hätte keine Möglichkeit mehr, die Oberfläche zu rendern... Vermutlich haben OS und Grafiktreiber jederzeit vollständige Kontrolle über den Speicher, was ja auch Sinn macht, sonst würden wir heute noch mit Assembler programmieren. :)
 
Zuletzt bearbeitet von einem Moderator:
Kannst Du subjektiv beurteilen, ob die Engine jetzt aus VRAM-Mangel z.b. die letzte Textursturfe einfach nicht freischaltet?
 
Ich habe das Tool erst eingeschaltet, nachdem das Spiel (RE2) geladen war. Siehe Vergleich im Anhang. Die Texturen waren extrem "unruhig". Die grüne Kurve hat eine deutlich höhere Streuung. Interessant ist übrigens, wie die VRAM-Auslastung ist nachdem man das Tool beendet. Zeigt sich dann, was das Spiel wirklich braucht??
 

Anhänge

  • RE2_VRAM_Allocator.png
    RE2_VRAM_Allocator.png
    202,8 KB · Aufrufe: 514
HisN schrieb:
Kannst Du subjektiv beurteilen, ob die Engine jetzt aus VRAM-Mangel z.b. die letzte Textursturfe einfach nicht freischaltet?

Scheint normal geladen zu werden. Hab extra das TAA ausgemacht, um die texturen in voller schärfe zu sehen. Ich kann auch zwischen den Texturstufen wechseln und sehe dann, wie die Texturen schärfer bzw. pixeliger werden. Funktioniert also bzw. wird dargestellt wie erwartet, egal ob mit oder ohne Reservierung.

Mit sicherheit sagen, ob auch wirklich die besten Texturen geladen werden kann ich nicht, ich kann aber zumindest sagen, dass die Texturen meist so scharf sind, dass meine Monitorauflösung nichtmal ausreicht, um sie in voller Schärfe aufzulösen. Da bräuchte ich wohl nen 4K Monitor. Also... ja, das werden schon die besten Texturen sein...


Wobei ich eins noch erwähnen muss. Das Spiel macht bei mir nicht mehr als 3,5 GB VRAM voll. Keine Ahnung, ob hier irgend eine 3,5 GB Sperre der GTX970 auch für meine GTX980 greift, aber ich bin mir sicher, dass das bei dem Game schonmal anders war. Andere Spiele machen die 4GB auch ganz voll.

Aber gut, viel ändert sich dadurch so oder so nicht.
Wenn ich 3,5 GB VRAM reserviere, sollte das in jeden Fall nen deutlichen Performancehit geben.
Tuts aber nicht. Die Daten werden einmalig ausgelagert und das wars dann.
Ergänzung ()

Noch ein Hinweis am Rande. Wollte grade auch mal ne Framtime Analyse mit OCAT machen.

Keine Ahnung, warum hier so viele auf das Tool schwören, aber bei mir scheint das leider überhaupt nicht gut zu laufen. Sobald ich das tool starte hab ich z.B. in SotTR nur noch 27-30 statt 40 FPS und das Spiel ruckelt wie hölle. Hab dann auch gefühlt Frametime Spikes drin, die vorher nicht drin waren. Die Messung hab ich mir dann direkt gespart. Habs dann auch extra zwei mal mit und ohne OCAT getestet, um sicher zu gehen, dass ich es mir nicht einbilde....
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: HisN
@Laggy.NET Du solltest unbedingt das Overlay abschalten in OCAT.

Nochmal zum Thema Swapping. Wenn ich das Tool den Speicher wieder freigeben lasse, dann fällt die VRAM Usage in Verbindung mit RE2 um eben diese allozierte Speichermenge. Wenn der Treiber einen Teil davon weggeswappt hätte, wäre das nicht der Fall. Unter 6GB wird RE2 richtig mies mit meinen Einstellungen. Harte Ruckler, wenn man Räume wechselt, schlechtere Texturen. Das Spiel fühlt sich komplett hakelig an.
 
Zuletzt bearbeitet von einem Moderator:
Lass das Tool mit dem Wert 1 laufen. Das beeinflusst die Menge an VRAM nicht, aber das Tool läuft.
Müsste man sehen können ob es die Frametimes beeinflusst.

Und es sind noch noch gar nicht "viele" die schwören :-)
 
Zurück
Oben