ARB_texture_storage wurde in OpenGL 4.2 Core eingeführt.Was bedeutet unveränderliche Textur?
Können Sie erklären, was Unveränderlichkeit für Texturobjekte bedeutet?
Warum ist es besser von der vorherigen Textur Verwendung und was sind die Nachteile dieser Funktion?
Ich weiß, ich kann die Spezifikation dieser Erweiterung lesen (was ich getan habe :)), aber ich würde gerne einige Beispiele oder andere Erklärungen sehen.
Lesen Sie die Einführung von der Verlängerung selbst:
The texture image specification commands in OpenGL allow each level
to be separately specified with different sizes, formats, types and
so on, and only imposes consistency checks at draw time. This adds
overhead for implementations.
This extension provides a mechanism for specifying the entire
structure of a texture in a single call, allowing certain
consistency checks and memory allocations to be done up front. Once
specified, the format and dimensions of the image array become
immutable, to simplify completeness checks in the implementation.
When using this extension, it is no longer possible to supply texture
data using TexImage*. Instead, data can be uploaded using TexSubImage*,
or produced by other means (such as render-to-texture, mipmap generation,
or rendering to a sibling EGLImage).
This extension has complicated interactions with other extensions.
The goal of most of these interactions is to ensure that a texture
is always mipmap complete (and cube complete for cubemap textures).
Die offensichtlichen Vorteile sind, dass die Umsetzung kann Vollständigkeit/Konsistenzprüfungen zur Laufzeit entfernen, und der Code ist robuster, weil Sie nicht versehentlich ein erstellen falsche Textur
zu erarbeiten: „unveränderlich“ bedeutet hier, dass die Textur Speicher (eine der drei Komponenten einer Textur: Lagerung, Sampling, Parameter) wird einmal zugeordnet und es ist schon komplette. Beachten Sie, dass Speicher nicht die Speicherinhalte bedeutet - sie können jederzeit ändern; es bezieht sich auf den logischen Prozess des Erwerbs von Ressourcen für diese Inhalte (wie ein malloc).
Mit nicht unveränderlichen Texturen, können Sie den Speicher jederzeit ändern, durch glTexImage<N>D Anrufe. Es gibt viele, viele Möglichkeiten, sich in den Fuß auf diese Weise Schießen:
Da Sie erlaubt sind glTexImage<N>D bei nennen jederzeit, muss die Implementierung immer überprüfen, bei Einzeichnungszeit, dass Ihre Textur legal ist. Unveränderlicher Speicher macht immer das Richtige für Sie, indem Sie alles auf einmal zuweisen (alle Mipmap-Ebenen, alle Cubemap-Gesichter usw.) mit dem richtigen Format. Man kann also keine Textur (leicht) mehr vermasseln, und die Implementierung kann einige Überprüfungen entfernen, was die Dinge beschleunigt. Und alle sind glücklich :)
danke für die Antwort.Ich sehe, dass diese Erweiterung im Allgemeinen die Komplexität reduziert und die Geschwindigkeit verbessern sollte. Wenn Sie eine einfache Textur von einem Datenträger geladen haben, sollten Sie TexStorage2D verwenden, um die gesamte Arbeit im Voraus zu erledigen. – fen
@fen * "Wenn Sie eine einfache Textur von einer Festplatte geladen haben" * - Nein, das sollte * lesen "Wenn Sie irgendeine Textur haben" *. –
"* Was sind die Nachteile dieser Funktion? *" Die Tatsache, dass es nicht in OpenGL 1.1 war. –
mögliches Duplikat von [Was macht glTexStorage?] (Http://stackoverflow.com/questions/9224300/what-does-gltexstorage-do) –
Es repariert im Grunde Designfehler in OpenGL. Abgesehen von sehr wenigen, wirklich interessanten Features, geht es in den meisten modernen OpenGLs eher um API-Änderungen als um neue Funktionen. Tatsache ist, dass wir jetzt eine genaue Vorstellung von GPU-Fähigkeiten haben (immer noch Platz für neue Sachen, wie XD) und wir brauchen bessere und konsistentere APIs, um den Benutzern Fähigkeiten zu bieten. – GameDeveloper