Hallo,

Ich arbeite gerade an meiner Basis für OpenGL3 und bin bei den Texturen auf ein Problem gestoßen.

Wenn ich bei der Funktion glTexImage als format den Token GL_BGR oder GL_BGRA angebe erhalte ich immer die Fehlermeldung INVALID_ENUM. Obwohl die Token laut den spec's nicht deprecated sind.
Verwende ich aber einen abwärtskompatiblen Kontext funktioniert es anstandslos.



Ich bin mittlerweile am verzweifeln da ich nirgends einen Anhaltspunkt finde.

MFG
humflo

Problem "gelöst".

Es handelt sich anscheinend um einen Fehler im NVidia Treiber, wenn man einen aufwärts kompatiblen Kontext verwendet.
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=256544

Habe die neueste Version installiert, aber der Bug wurde noch nicht behoben.

MFG
humflo

Mittlerweile ist ja der OpenGL 3.2 Treiber schon 99,9% konform. Ist der Fehler jetzt behoben?
Sollte man immer bzw. kann man einen OpenGL 3.2 "core" & aufwärtskompatiblen Kontext erstellen?
Wenn ich das richtig verstanden habe bedeutet aufwärtskompatibel, dass man schon heute auf Funktionen verzichtet, die erst morgen aus den Treibern gestrichen werden.

Es kommt auch auf die Karte an, ob diese es überhaupt schon unterstützt, die G80 sind die Karten, die aktuell alle Farbformate unterstützen.
http://developer.download.nvidia.com/opengl/texture_formats/nv_ogl_texture_formats.pdf
Wichtig ist auch, das BGRA und RGBA unterschiedliche Pixelformate sind und OpenGL ledeglich wegen Direct3D beide in den Support genommen hat.
OpenGL arbeitet intern mit rgba und direct3d mit bgra, wenn du also etwas anderes als rgb oder rgba nimmst, dann muss jedes mal, sobald ein texel(von fbo) angefasst wird ein swizzle passieren, das kostet viel Rechenzeit und ist einer der einfachsten Möglichkeiten viel Performance aus OpenGL Apps wieder raus zu holen. Einfach Texturen vorher swizzeln(komponentenweise austauschen), damit die Texturen immer als rgba über den Bus gehen. ATI und NV haben in ihren HowTo optimize Artikeln genau dieses immer am Anfang stehen. Sobald ein nicht RGBA passende Textur generiert wird(auch wenn internes und externes Pixelformat sich unterscheiden), tut der Treiber das swizzle intern selber und schickt dann erst die Daten über den Bus(CPU seitig und total unoptimiert wegen Kompatibilitätsgründen wie Matrizen Stack). BGRA ist wie gesagt nur zur Kompatibilität zu Direct3D vorhanden und kam auch entsprechend erst später in die Karten rein. OpenGL3 hat aus Performancegründen da stark sortiert und so viel wie möglich aus den Treiber geworfen, was auf CPU ausgeführt wird, damit der User Performantere Lösungen nutzen kann. Folgender Link ist recht frisch und hat mich sogar recht geschockt, da NV mit einigen Mythen aufräumt und sagt, dass nichts aus dem Treiber verschwindet, er nicht kleiner wird, nicht langsamer oder schneller. Die Unit und Smoke Tests laufen über alle Features im Treiber auch in neueren Versionen und werden auch weiter hin gepflegt. OpenGL3 hat den Treibercode nicht verringert sondern vergrößert aber mit den Profilen kann man eine bessere Übersicht bekommen was auf aktuellen Karten effizienter arbeitet und ist auch Werbewirksamer wenn es regelmäßig neue Versionen gibt(3 neue Versionen innerhalb von nicht mal 2Jahren).
http://www.slideshare.net/Mark_Kilgard/opengl-32-and-more

@humflo ja es ist ein Bug und im opengl.org forum hat man auch geschrieben dass er schon NV bekannt ist. Ich bin auch schon drüber gestolpert -_-

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Der Bug wurde laut meinen Beobachtungen mit der Treiberversion in der, der OpenGL 3.1 Support wider hinzugefügt wurde, behoben (welche Version es war weiß ich nicht mehr). Arbeite jetzt mit einem aufwärtskompatiblen 3.0 Kontext und habe keinerlei Probleme.

@TAK2004
Ich dachte wenn man mittels glTexImage und ohne spezielle Vorgabe des internen Format, Texturen hochlädt, konvertiert der Treiber es in das am besten passende Format. Und beim eigentlichen Rendervorgang ist keine Konvertierung mehr nötig.

Jupp, das ist vieleicht ein bischen im Text untergegangen aber das meinte ich, die CPU muss noch beim laden extra eine Konvertierung machen, wenn man Texturdaten hoch lädt und das kostet viel Zeit, da das alles unoptimiert über die Bühne geht. Es ist effizienter die konvertierung selber zu machen und z.B. MMX oder ähnliches zu nutzen, bzw. gleich die Daten im geeigneten Format ablegen
Ich hatte meine Texturen mal von BGRA in RGBA umgewandelt und der Ladeprozess war mehr als doppelt so schnell, nachdem ich dann von PNG auf DXT5 gegangen bin war der Unterschied bei weitem größer. Zur Laufzeit muss man ledeglich bei FBOs und Shadern aufpassen. Ich hatte mal gelesen, das durch ein falschen FBO zufolge haben kann, das die gpu anfängt eine menge swizzle operationen im Shader aus zu führen. Das gleiche gilt übrigens auch für VBO und interleaved, immer in XyzwRgbaUv00 Reihenfolge speichern, da sonnst der vertexshader vor starten des codes jedes mal ne menge operationen machen muss,um die daten in 4xfloat pattern zu bekommen und auch die 2xfloat UV koordinaten werden intern in 4xfloat Register gepackt, darum die letzten 2 floats leer lassen oder mit irgendwelchen Daten auffüllen(sonnst füllt die GPU automatisch mit 0 auf und kostet genauso viel Zeit). Zu dem Thema gibt es leider nur eine Handvoll Whitepapers von AMD und Nvidia und man muss sie mit der Lupe suchen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004