Meine Suche im Web hat leider nur Vorschläge für ein besseres Speichermanagement in OpenGL 2.0 zu Tage gebracht, aber leider nicht meine Frage beantwortet wie es bei der momentanen API aussieht

Ich will wissen wie OpenGL mit den Texturen verfährt wenn der insgesammte Speicherbedarf für Texturen die Kapazität des VRAM übersteigt. Führt OpenGL einfach Buch darüber welche Texturen zuletzt gebunden wurden und löscht bei Bedarf einer Textur - die noch nicht im VRAM liegt - einfach genug von denen die schon im VRAM liegen - aber lange nicht mehr benutzt wurden - und lädt die benötigte Textur über den AGP?

Das ist die einzige Mechanik die ich mir desbezüglich vorstellen kann, da ich mehr Texturen laden kann als meine Grafikkarte Speicher hat und alle Texturen korrekt geladen und verfügbar sind. Bitte klärt mich mal auf! Danke im Vorraus

Du hast nichts gefunden, da für OpenGl < 2.0 ein entsprechender und einheitlicher Mechanismus nicht existiert. Es ist absolut Treiberabhängig, wie die Texturen gemanaged werden. Das liegt daran, dass OpenGl zu einer Zeit entwickelt wurde, wo es 3D Karten in ihrer heutigen Form noch gar nicht gab, da lagen alle Texturen noch im Hauptspeicher des OpenGl-Servers.
Es gibt zwar eine Funktion, ob eine Textur Resident ist, aber diese bringt dich nciht weiter, da jeder Treiberentwickler darunter etwas anderes versteht.

Wäre es besser die Texturen erst bei Bedarf zu Laden und nach Benutzung wieder zu Entfernen? Ich lade momentan alle Texturen für das Menüsystem direkt nach der Initialisierung von OpenGL, da ich aber nur einen Bruchteil davon pro Screen benötige ginge es wohl, beim Sprung in ein anderes Menü, die nicht mehr benötigten Texturen zu Löschen und neue zu Laden. Allerdings benötigt jeder Screen gut 5MB (unkomprimiert) mit Hintergrund/Buttons/Icons und manche Screens teilen sich Texturen, weshalb ich die momentane Lösung nicht schlecht fand. Ich befürchte das permanentes Nachladen die Benutzung der Menüs träge macht

Dank Dir auf jeden Fall, ich werd nochmal google füttern - vielleicht find ich ja genauere Information wie die Nvidia/ATI Treiber damit verfahren.

[edit]nvidia und ati webseiten haben sich beide als nicht sonderlich hilfreich erwiesen.

Evtl. wäre es eine Alternative sie einfach mit glPrioritizeTextures in den VRAM zu "zwingen", anstatt die Texturen für jeden Screen erneut zu laden und dann wieder zu löschen?[/edit]

Das hört sich zwar gut an,allerdings gibts immernoch jede Menge Grafikkarten auf denen glPrioritizeTextures nichts bringt.

Die Sache mit der Texturenverwaltung ist halt sehr anwendungsspezifisch,und natürlich auch von der Zielplattform abhängig.An deiner Stelle würde ich,wenn die Menüs eine recht roße Rolle spielen (also oft genutzt werden) die Menüs immer im VRAM halten,diese jedoch dort komprimiert über eines der S3TC/DXT-Formate hochladen.Die komprimierten Texturenformate haben einen festen Kompressionsration,und besonders bei Texturen mit vielen unterschiedlichen Farbbereichen fällt diese kaum auf.Vorteil ist halt der kleinere Platzanspruch im VRAM,und auch Bandbreite bei der Übermittlung der Texturen zwischen VRAM und GPU.
Ausserdem würde ich Menüs in zwei "Bereiche" unterteilen.Zum einen die Hintergrundgrafik,und zum anderen den Text.Die Hintergrundgrafik würde ich dann in einer geringeren Auflösung laden (z.B. 512x512) und den Text selbst zeichnen.Dadurch sparst du auch wieder viel VRAM.
Wenn dein Spieler allerdings erst in ein oder zwei Jahren fertig wird,hat sowieso fast jeder 3D-Beschleuniger >64 MByte Speicher,und du musst dir dann evtl. keine Sorgen mehr um den VRAM machen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Jetzt bin ich noch mehr verwirrt, der Befehl ist in der OpenGL 1.1 Spezifikation enthalten und funktioniert nicht identisch mit jedem Treiber? Ich dachte bis jetzt das die Spezifikation genau deswegen existiert

Welche Grafikkarten kommen denn nicht mit glPrioritizeTextures(); zurecht? Ich benutze nicht mal den neusten nvidia Treiber und die Grafikkarte hat keinerlei Probleme mit mehr geladenen Texturen als in den Grafikkarten-speicher passen.

[optimierungen]
Da das komplette Mikromanagement über diese Screens abläuft, befindet sich gar kein Text auf den Texturen (-> glprint). Texturkompression hatte ich schon in Betracht gezogen, aber bei Texturen, die pixelgenau dargestellt werden, sieht man den Farbverläufen die Kompression an. Ich werde wohl nochmal mit dem Rotstift durch die Screens gehen müssen und etwas kürzen. Du hast mich mit den "Bereichen" auch auf eine Idee gebracht, ich benutze zwei 512² Texturen nebeneinander für den Hintergrund, die in jedem Screen unterschiedlich sind. Evtl. wäre es am einfachsten nur diese 2 Texturen bei jedem Screen-wechsel zu Löschen und zu Laden - Danke für den Denkanstoß, ich werde das mal untersuchen


Bis dahin dürfte OpenGL 2.0 auch verabschiedet worden sein, was hoffentlich vernünftiges Memory-management mitbringt, die Vorschläge, die ich bei meiner Suche gefunden hatte, hörten sich nicht schlecht an. Ich denke es wäre wohl am besten erstmal nur minimale Optimierungen vorzunehmen und die endgültige Lösung mit 2.0 zu entscheiden - auf meinem System läuft es ja problemlos. Zur Not kann ja immer noch ein Safe-Mode eingebaut werden, der bei jedem Screen alle Texturen löscht und neu lädt

Dank Dir ebenfalls

edit: http://www.gamasutra.com/features/19990723/opengl_texture_objects_07.htm
Jetzt ist die Verwirrung perfekt, der Author dieses Artikels hat auch die OpenGL Superbible geschrieben

Was verwirrt dich denn an dem Artikel?Sowohl von glPrioritizeTextures als auch von glAreTexturesResident weis ich,das besonders ältere Grafikkarten (Matrox,3Dfx,Kyro) diese entweder fehlerhaft oder nur teilweise implementiert haben.Wenn du auch Nutzer solcher Grafikkarten erreichen willst,dann solltest du die Finger von diesen Funktionen lassen.Ich würde die Texturenverwaltung ganz einfach OpenGL überlassen,und solange du nicht mehr VRAM belegst als vorhanden ist (und davon hast du in einem AGP-System ja recht viel,nämlich VRAM+AGP Aperature Size) würde ich mir da keine großen Gedanken drum machen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Zumindest beim NVidia Treiber habe ich das mit den Buffer Objekten mal ausprobiert. Die wurden erst aus dem Video Speicher in den normalen Speicher und schließlich bis in die Auslagerungsdatei verschoben. Vermutlich haben die in ihrem Treiber eine einheitliche Speicherwaltung und mit Texturen ist das ähnlich.

Das ist die Information die ich wollte Um Voodoo und Co. mache ich mir keine Gedanken, ich will nicht die Eier legende, Plastik fressende, Wollmilchsau die auch auf einem 286er noch 100fps rendert, sondern lediglich das es ab Riva TNT mit 16MB aufwärts problemlos läuft.
Kann man pauschal sagen, daß alle Treiber für AGP 3D Beschleuniger das LRU (Least Recently Used) Texture swapping verwenden? (denke da jetzt speziell an ATI-karten, nvidia hat ja einen einheitlichen Treiber)



Mit meinem nvidia Treiber geht es ja auch anstandslos, mir ist halt gedämmert das ich überhaupt nicht weiß wie OpenGL die Texturen intern verwaltet - und wer nicht fragt bleibt dumm

Ich finde diese Art vom Speichermanagement gar nicht so schlecht, es mag wohl nicht zufriedenstellend sein wenn sich noch display Listen und Shader im Speicher tummeln und durch nicht kontrollierbares swapping fragmentierung entsteht, die die Performance beeinflußt, aber für reines Texture-management finde ich das vollkommen ausreichend.

P.S. Das Thema wäre wohl einen Absatz im Tutorial zum Texture Mapping wert? *duckt sich und rennt weg*

Ich denke nicht. Was hat ein Anfänger, der grad seine ersten Übungen mit Texturen macht von dieser Information? Das verwirrt mehr, als dass es etwas bringt.

Das ist ja das Problem.Z.B. die G400/450/550 von Matrox sind leistungsmäßig in der TNT2(Ultra)-Klassen einzuordnen,und da die G400 (hatte selbst eine) damals eine sehr beliebte Karte war,wirds wohl noch jede Menge Rechner mit solchen Karten geben.Allerdings waren die Matrox OpenGL-Treiber schon immer grauenvoll.Genauso bei der KyroI/II,die ja auch noch sehr beliebt sind (Konkurrenz zu GF2 & Co.),und deren OpenGL-Treiber auch nicht das Gelbe vom Ei sind.Wenn du also die TNT-Grafikkartengeneration als Ziel hast,dann musst du solche Karten einfach in deinem Quellcode berücksichtigen...problematisch wirds halt nur wenn du keine Möglichkeiten hast es auf diesen Karten zu testen.


Bei ATI und NVidia (die ATI-Treiber brauchen sich übrigens nicht von denen von NVidia zu verstecken,momentan eher umgekehrt) bin ich mir zu 100% sicher das dieses (sehr sinnvolle) Verfahren angewendet wird.Allerdings hab ich persönlich es noch nie geschafft meine 128 MByte VRAM so voll zu stopfen,das irgendwelche Texturen über den AGP-Bus in den Hauptspeicher gescheffelt werden mussten.


Ich bin mir eigentlich komplett sicher,das ein guter Grafikkartentreiber Fragmentierungen im VRAM zu vermeiden weis,und notfalls auch "umsortiert".Von daher würde ich mir da mal keine Sorgen machen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Naja, ich dachte einfach an ein paar Zeilen wo schlicht und ergreifend erwähnt wird das es aufgrund unterschiedlicher Treiberqualität zu Problemen kommen kann, wenn mehr Texturen geladen werden als Speicher vorhanden ist, da man dann der Wilkür des Treibers ausgeliefert ist. Keinen Roman, einfach nur eine Notiz.


Da das ganze nicht kommerziell wird, muss es ja nicht auf allen Karten laufen - ich werd einfach im Treiber-namen nach den strings "ati" und "nvidia" suchen und wenn keiner von beiden vorhanden ist kommt ne Nachricht:



Spaß beseite, ich werde mich vorerst auf die Treiber verlassen und mit glPrioritizeTextures(); arbeiten, dadurch habe ich auch später einen Ansatz wo ich noch eine Routine einbauen kann um die Texturen manuell zu Löschen/Laden, sollte es auf allen Grafikkarten, die nicht von ATI/NVidia kommen, Probleme geben.

bzgl. ATI vs. NVidia Treiber hast Du recht, der neuste Detonator für win98 lässt mich für die GF2 keine Auflösung über 640x480 einstellen, daher benutzt ich wieder einen älteren build