C++ SDL_Texture belegt VRAM + RAM?

[Crax]

Hallo Programmierfreunde!

Ich hätte da mal eine Frage bezüglich der SDL_Texture.

//Erstelle Texture
SDL_Texture *texture = NULL;

//Lade Bild in die Texture
texture = IMG_LoadTexture("texture.png");

//Zeichne die Texture auf den Bildschirm
SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, texture, NULL, NULL);
SDL_RenderPresent(renderer);

Zeile 5. könnte man auch hiermit ersetzen

//Erstelle Surface
SDL_Surface *temp_surface = NULL;
//Lade Bild in die Surface
temp_surface = IMG_Load("texture.png");

//Lade Bild in die Texture mittels Surface
texture = SDL_CreateTextureFromSurface(temp_surface);
//Lösche Surface
SDL_FreeSurface(temp_surface);

Das funktioniert alles ohne Probleme, habe mit SDL(2) schon etwas Erfahrung sammeln können, nur eine Sache verstehe ich nicht ganz:

Eine SDL_Surface liegt ja im Hauptspeicher (RAM) und mit der kann ich keine Hardwarebeschleunigung nutzen. Nur wenn ich jetzt eine Texture durch eine Surface erstelle und diese Surface dann wieder lösche , dann sollte die Texture doch auch nur im VRAM liegen? (oder ich lade das Bild gleich als Texture in den VRAM mit IMG_LoadTexture, sollte nur zu Veranschaulichung dienen)

Wenn ich nun aber die Texture erstelle steigt der VRAM und der RAM Verbrauch. Bei einem 1920x1080 großem Bild steigt der VRAM um ca. 10MB und der RAM um ganze 16MB an.

Ist das normal oder habe ich die ganze Zeit etwas falsch gemacht? Sollte die Texture nicht nur den VRAM belasten? Konnte in der Dokumentation leider nichts darüber finden.

Danke schon mal im voraus.

 

[VikingGe]

Das könnte man mal testen, indem man nicht eine Textur, sondern 100 Texturen lädt. Möglicherweise wird da bei SDL noch irgendetwas initialisiert, möglicherweise hält SDL auch tatsächlich noch eine weitere Kopie der Pixeldaten vor - aber auch der Grafiktreiber wird für das Textur-Objekt natürlich noch etwas RAM reservieren.

Da könntest du auch nicht viel gegen tun, aber wenn der Speichereffizienz wichtig ist, wäre es vielleicht nicht die dümmste Idee, direkt mit OpenGL zu rendern und sich da irgendein intelligentes Textur-Management auszudenken.

 

[Crax]

Danke für die Antwort.

Also es wird definitv noch etwas im RAM gespeichert und sehr wahrscheinlich wird das eine Kopie sein. Der Verbrauch steigt immer weiter und weiter je mehr Texturen ich lade.

Tragisch ist das jetzt nicht unbedingt, ich find's nur unnötig. Vorallem weil der RAM schneller ansteigt als der VRAM. Über OpenGL hab ich mir auch schon mal gedanken gemacht, habe aber das Gefühl, dass OpenGL etwas übertrieben wäre für das was ich vorhabe. (Sprites laden und bewegen, evtl. etwas manipulieren wie rotieren, spiegeln oder colormods)

Vielleicht ist das aber auch nur eine Ausrede von mir, weil ich dann wieder die ganzen Funktionen unter OpenGL lernen müsste.

 

[Crax]

Hat nicht mehr viel mit dem Thema zu tun, aber ich möchte dafür nicht extra einen neuen Thread erstellen.

Ich suche jemanden mit einem Montior über 60Hz (oder unter) und evtl. auch eine Auflösung über 1080p. Falls dieser Lust und Zeit hat (2 Minuten) könnte er vielleicht kurz mal mein Programm starten. Als Betriebssystem wäre Windows 7/8 am besten geeignet, sollte aber auch unter XP und 10 laufen.

Es öffnen sich zwei Fenster, das eigentliche Programm und die Console zur Analyse. Der wichtige Teil ist eigentlich in der Console und zwar ob das Ausgelesene dort auch stimmt (Hz, Auflösung). Das Wichtigste ist allerdings was die "Loops per second" anzeigen, diese sollten immer ~100 betragen. (außer das Fenster wird verschoben/festgehalten)

Wer lust hat kann auch testen wie sich das Programm bei ihm verhält wenn er es per ALT+Enter in den Fullscreen bringt. Die Buchstaben von "Computerbase" sollten außerdem rot aufleuchten wenn man mit der Maus drüber geht.