Het opslaan van veel kleine texturen in OpenGL

Ik bouw een OpenGL-app met veel kleine structuren. Ik schat dat ik er een paar honderd zal hebben texturen op het scherm op elk gewenst moment.

Kan iemand best practices aanbevelen voor het opslaan van al deze texturen in het geheugen om potentiële prestatieproblemen te voorkomen?

Ik ben ook geïnteresseerd in het begrijpen van hoe OpenGL texturen beheert. Zal OpenGL proberen ze op te slaan in het GPU-geheugen? Zo ja, in hoeveel GPU-geheugen kan ik rekenen? Zo nee, hoe vaak geeft OpenGL de texturen uit het toepassingsgeheugen door aan de GPU en moet ik me zorgen maken over latentie wanneer dit gebeurt?

Ik werk met OpenGL 3.3. Ik ben van plan alleen moderne functies te gebruiken, d.w.z. geen dingen met onmiddellijke modus.

2

1 antwoord

  1. Als u een groot aantal kleine structuren hebt, kunt u deze het best combineren in een enkele grote textuur met elk van de kleine structuren in bekende subgebieden (een techniek die soms een "textuuratlas" wordt genoemd). Overschakelen naar welke textuur gebonden is, kan duur zijn, in die zin dat het beperkt hoeveel van uw tekening u samen kunt batchen. Door er een te combineren, kunt u het aantal keren dat u opnieuw moet binden minimaliseren. Als alternatief, als uw texturen een vergelijkbare grootte hebben, kunt u kijken naar het gebruik van een array-structuur (introductie hier ).
  2. OpenGL probeert uw texturen zoveel mogelijk in het GPU-geheugen op te slaan, maar ik geloof niet dat het gegarandeerd is dat het daadwerkelijk op de grafische kaart staat.
  3. De hoeveelheid GPU-geheugen die u beschikbaar hebt, is afhankelijk van de hardware waarop u draait en de andere eisen aan het systeem op het moment dat u het uitvoert. Wat precies "GPU-geheugen" betekent, varieert per computer, het kan discreet zijn en alleen worden gebruikt voor de GPU, gedeeld met het hoofdgeheugen of een combinatie van beide.
  4. Ervan uitgaande dat uw toepassing de texturen niet voortdurend wijzigt, hoeft u zich niet speciaal zorgen te maken over latentiekwesties. U geeft OpenGL eenmaal de texturen en vanaf dat moment zal het hun locatie in het geheugen beheren. Ervan uitgaande dat u niet meer textuurgegevens nodig hebt dan gemakkelijk in elk GPU-geheugen in het frame past, hoeft u zich geen zorgen te maken. Als u toch een grote hoeveelheid textuurgegevens moet gebruiken, probeer dan ervoor te zorgen dat u alle gebruikte batches samen gebruikt om het aantal rondreizen dat de gegevens moeten maken te minimaliseren. U kunt ook kijken naar de ingebouwde structuren voor textuurcompressie en zoiets als GL_COMPRESSED_RGBA leveren aan uw oproep naar glTexImage2D , zie man pagina voor meer details.

Natuurlijk, zoals altijd, is uw beste weddenschap om deze dingen zelf te testen in een situatie die dicht bij uw verwachte use case ligt. OpenGL biedt een groot aantal garanties, maar veel zal variëren afhankelijk van de specifieke implementatie.

8
toegevoegd
+1 voor textuuratlasing. Geweldige methode. Ik hoop dat er voldoende tutorials zijn om het te implementeren.
toegevoegd de auteur Marnix, de bron
Bedankt! Dat is geweldig. Wat betreft zelfstudies: het klinkt alsof textuuratlasing in principe hetzelfde idee is als sprite-sheets, waarover er veel bronnen beschikbaar zijn. Vraag: Wat ik elders heb gelezen, suggereert dat ik meestal op ten minste 256 MB aan GPU-geheugen kan rekenen, en als mijn texturen + geometrie dat overtreffen, neem ik een grote prestatiehit. Klinkt dat goed?
toegevoegd de auteur rlkw1024, de bron
@Jarrett 256 MB klinkt als een redelijk redelijke ondergrens, ervan uitgaande dat je geen low-end computers target. Alles met een afzonderlijke grafische kaart van de afgelopen 4 of 5 jaar moet minimaal 256 MB VRAM bevatten. Als u zich richt op nieuwere, recentere computers, kunt u er echter minstens twee keer op vertrouwen. Zelfs laptops met speciale kaarten hebben tegenwoordig vaak een gig van VRAM.
toegevoegd de auteur nonVirtualThunk, de bron