Der OpenGL Extension-Wahn geht in die nächste Runde.

[Demirug]

ARB Meeting Node Spetember 10 (http://www.opengl.org/about/arb/notes/meeting_note_2003-09-10.html)

Extending the OpenGL Shading Language
In the working group, we pulled out several features - texture rectangle fetches and draw buffers. How do we extend the language? Suggestions: for function names, ala C++ (ATI::<name>). For variables and tokens, continue to use postfix (FOO_ATI) convention. Alternatively, just use postfix convention everywhere. Will continue discussing in working groups.

Was soll das nun schon wieder?

Für was gibt es eine einheitliche Sprache wenn dann doch wieder jeder seine eigene Funktionen dazu bauen darf?

Bei einem "normalen" Compiler mag das ja gerade noch angehen aber doch nicht bitte bei etwas was auf jeden Fall portabel sind soll. OK, man müsste die Hersteller spezifischen Funktionen ja nicht nutzen aber aleine die Möglichkeit dazu nimmt von den IHVs den Druck sich einig zu werden. Zudem ist mir auch noch nicht ganz klar wie das mit dem Abfragen ob eine Funktion nun vorhanden ist oder nicht ablaufen soll. Etwa über den Extensions-String?

Bei solchen Ideen brauchen sie sich jedenfalls nicht zu wundern warum sich immer weniger Entwickler für OpenGL begeistern können.

[Chris Lux]

schande!
gerade die texture rectangles sollten schon lange standardisiert sein. meine freude auf ogl2.0 legt sich langsam wirklich.

:(

ich denke schon, dass man die extensionstrings durchsuchen muss bevor man sein programm an den compiler geben kann, sonst wirds sicher fehler hageln.

nochmal schande!

[Matti]

eigentlich finde ich OpenGL viiieeel besser als D3D, aber das mit den Hersteller-spezifischen Extensions kotzt mich auch an. Das mit den Extensions ist zwar ein gutes Konzept, aber sie müßten wenigstens einheitlich sein.

[Lord Nikon]

Mal als Laie gefragt :
Bringt das nicht Vorteile wenn die Hersteller ihre eigenen Extention veröffentlichen , da diese warscheinlich richtig für die eigende Hardware optimiert sind ? Dürfte doch eigentlich einen passable Geschwindigkeitszuwachs geben wenn man solche optimierte Funktion nimmt oder ?

[x-dragon]

Original geschrieben von Lord Nikon
Mal als Laie gefragt :
Bringt das nicht Vorteile wenn die Hersteller ihre eigenen Extention veröffentlichen , da diese warscheinlich richtig für die eigende Hardware optimiert sind ? Dürfte doch eigentlich einen passable Geschwindigkeitszuwachs geben wenn man solche optimierte Funktion nimmt oder ? Grundsätzlich natürlich schon, aber die Entwickler haben natürlich auch keinen Bock für jede Grafikkarte einen eigenen Pfad zu programmieren und vor allem wenn die Funktionen an sich sehr ähnlich oder sogar gleich sind, aber halt jeder Hersteller dem einen anderen Namen gibt.

[Demirug]

Original geschrieben von Lord Nikon
Mal als Laie gefragt :
Bringt das nicht Vorteile wenn die Hersteller ihre eigenen Extention veröffentlichen , da diese warscheinlich richtig für die eigende Hardware optimiert sind ? Dürfte doch eigentlich einen passable Geschwindigkeitszuwachs geben wenn man solche optimierte Funktion nimmt oder ?

Wie x-dragon schon sagt ist es schwer in einem solchen Umfeld Entwickler zu motivieren. Ein Punkt über den man bei diesem Treffen ebenfalls diskutiert hat.

Das grosse Problem bei den Extensions ist das aufgrund dieser Möglichkeit einfach kein Druck auf die IHVs entsteht sich auf eine Lösung zu einigen. Bei DX bekommt man ein Feature nur rein wenn man einen Konsens mit allen Beteiligten finden.

[Blutgrätsche]

Das OpenGL-API war mal als HW-Abstraction-Language gedacht, das eben von den konkreten HW-Implementationen der IHV abstrahiert. Extensions widersprechen diesem Konzept, wären aber noch akzeptabel, wenn man es eben nicht übertreiben würde. Einige Extensions scheinen ohnehin eher Work-arounds oder Zwischenlösungen von nur teilweise funktionierenden, nicht mehr rechtzeitig fertiggestellten oder nicht sauber konzipierten HW-Features zu sein (wenn ich Demirugs und B3D-Andys Postings mal re-interpretiere).

[zeckensack]

Demirung,
ich weiss jetzt nicht wo das Problem liegen soll. Es stellt sich natürlich die Frage, wie man die Sprache erweitern soll - eben weil man nicht mit Versionsnummern arbeitet, und auch nicht auf neue Runtimes warten will, um neue Features nutzen zu können. Darüber muss man sich früher oder später Gedanken machen, eher früher, wenn man zu einer guten Lösung kommen will.

Zudem wurden hier zwei konkrete Features angesprochen: MRTs und neue texture targets (in diesem Fall RECT). Das gab's eben noch nicht, als die Sprache definiert wurde. Soll man GLSL jetzt deswegen wegwerfen?

Früher oder später sollte dich wirklich mal jemand dazu zwingen, einen GL-Renderer zu schreiben. So schlimm ist das nämlich garnicht.

[Demirug]

Nein, Die Extensions funktionieren eigentlich immer ganz gut und sind auch hervoragend dokumentiert. Das Problem ist eben nur das wenn ein IHV eine Extension einbaut dann ist die eben sehr genau auf seine eigene Hardware zugeschnitten. Andere IHVs können dann in der Regel selbst wenn sie wollte diese Extension nicht anbieten weil ihre Hardware nach einen anderen Konzept aufgebaut ist. So entstehen unter dem Deckmantel von OpenGL lauter kleine properitäre APIs der IHVs.

Das kann OpenGL auf noch so vielen Plattformen verfügbar sein was nützt das wenn die Portabilität zwischen unterschiedlichen Grafikchips auf der gleichen Plattform nur mangelhaft ist? Das Problem der unterschiedlichen Grafikchips hat jeder Entwickler aber kaum einer ziehlt auf den Linux oder Mac Markt.

Ich hatte viel Hoffung in glslang gesetzt. Auch wenn sich das erst dann wirklich ausgewirkt hätte wenn man alles vor NV30 und R300 nicht mehr berücksichtigen muss. Wenn glslang aber nun genauso Extensionverseucht wird wie es OpenGL im Moment ist sehe ich schwarz.

[Coda]

Du kannst doch GLSlang auch ohne die Extensions benützen
Wo ist das Problem?

[Demirug]

Original geschrieben von zeckensack
Demirung,
ich weiss jetzt nicht wo das Problem liegen soll. Es stellt sich natürlich die Frage, wie man die Sprache erweitern soll - eben weil man nicht mit Versionsnummern arbeitet, und auch nicht auf neue Runtimes warten will, um neue Features nutzen zu können. Darüber muss man sich früher oder später Gedanken machen, eher früher, wenn man zu einer guten Lösung kommen will.

Zudem wurden hier zwei konkrete Features angesprochen: MRTs und neue texture targets (in diesem Fall RECT). Das gab's eben noch nicht, als die Sprache definiert wurde. Soll man GLSL jetzt deswegen wegwerfen?

Mein Problem ist das "ATI::" bzw "_NV". Würde man sich darauf festlegen das nur noch das ARB neue Funktionlibs definieren darf und man dann abfragen kann welche dieser Zusatzlibs eine Karte unterstützt wäre das für mich ein gangbarer Weg. Aber wenn wieder jeder IHV einbauen darf was er will ist einfach (entschuldigung) Schrott.

Früher oder später sollte dich wirklich mal jemand dazu zwingen, einen GL-Renderer zu schreiben. So schlimm ist das nämlich garnicht.

Dreiecke habe ich auch schon rotieren lassen. Bei meinem Shader Framework würde ich unter OpenGL aber ein riesiges Problem bekommen das ich für fast jeden Chip einen Cross-Compiler schreiben müsste welche auf die dort benutzte properitäre Extension aufbaut. Es gibt in meinem Verzeichnissbaum sogar ein OpenGL Verzeichniss. Darin liegt aber derzeit nur eine Textdatei in der steht: "Warten was sich mit glslang machen lässt. Cg ist ja wohl tot". Damit das ich eine Multi-API Schnittstelle vorgesehen haben waren nicht alle einverstanden.

[Demirug]

Original geschrieben von Coda
Du kannst doch GLSlang auch ohne die Extensions benützen
Wo ist das Problem?

Das kein Druck da ist notwendige Erweiterungen zu vereinheitlichen wenn jeder IHV machen darf was er will.

[Gast]

Original geschrieben von Demirug
Mein Problem ist das "ATI::" bzw "_NV". Würde man sich darauf festlegen das nur noch das ARB neue Funktionlibs definieren darf und man dann abfragen kann welche dieser Zusatzlibs eine Karte unterstützt wäre das für mich ein gangbarer Weg. Aber wenn wieder jeder IHV einbauen darf was er will ist einfach (entschuldigung) Schrott.


Also quasi eine zentrale Extensionverwaltung?
Würd ich eigentlich auch für sinnvoll ansehen.
Es wär auch wunderschön die Extensions verschiedener Hersteller grösstenteils kompatibel wären.
*träum*

[Bringhimup]

Original geschrieben von Gast
Es wär auch wunderschön die Extensions verschiedener Hersteller grösstenteils kompatibel wären.
*träum*

Dann bräuchte man doch keine ;)

[ow]

.

[Crushinator]

Original geschrieben von Demirug
Mein Problem ist das "ATI::" bzw "_NV". Würde man sich darauf festlegen das nur noch das ARB neue Funktionlibs definieren darf und man dann abfragen kann welche dieser Zusatzlibs eine Karte unterstützt wäre das für mich ein gangbarer Weg. Aber wenn wieder jeder IHV einbauen darf was er will ist einfach (entschuldigung) Schrott. :kratz2: Ehrlich gesagt, verstehe ich "Dein Problem" nicht ganz. Denn "Du" beschwerst Dich auch nicht, daß der Borland C++ Builder eigene Extensions mitbringt, die vom ANSI* abweichen, man nutzt sie nur nicht, wenn der Code "portierbar" sein soll.

Außerdem ist es doch so - wenn ich es bisher so richtig mitbekommen habe - daß viele Extensions früher oder später in eine ARB-Version hinübergerettet werden. Insofern kann ich nichts schlechtes daran finden, wenn "Extensions" in einer herstellerspezifischen Version etwas früher "veröffentlicht" werden. Für mich hört sich das nämlich genau so an, wenn der eine Hersteller x mehr Tex. Depenend-Reads in einem DX-Shader unterstützt als der Andere. :ratlos:

[Demirug]

Original geschrieben von crushinator
:kratz2: Ehrlich gesagt, verstehe ich "Dein Problem" nicht ganz. Denn "Du" beschwerst Dich auch nicht, daß der Borland C++ Builder eigene Extensions mitbringt, die vom ANSI* abweichen, man nutzt sie nur nicht, wenn der Code "portierbar" sein soll.

Da spielt es ja auch primär keine Rolle weil der Compiler hier auf meinen Rechner seinen Dienst tut. Welcher Compiler auf einem anderen Rechner arbeit braucht mich da nicht zu interesieren weil ich nur Code ausliefere der Herstellerneutral ist (läuft auf allen x86 CPUs).

Außerdem ist es doch so - wenn ich es bisher so richtig mitbekommen habe - daß viele Extensions früher oder später in eine ARB-Version hinübergerettet werden.

Es gibt mehr als genügend die es nicht sind. Es gibt bis heute keine allgemeine Extension um die Pixelshading Funktionen einer DX8 Karte unter OpenGL zu nutzen. Und selbst wenn fehlt da einfach die Plannungssicherheit.

Insofern kann ich nichts schlechtes daran finden, wenn "Extensions" in einer herstellerspezifischen Version etwas früher "veröffentlicht" werden. Für mich hört sich das nämlich genau so an, wenn der eine Hersteller x mehr Tex. Depenend-Reads in einem DX-Shader unterstützt als der Andere. :ratlos:

Es gibt einen grossen unterschied zwischen Extensions bei OpenGL und Caps bei DX. Bei den Extensions hat man Narrenfreiheit. Bei den Caps kann man nur im vorgebenen Rahmen arbeiten. Unterstützt also A ein Feature und B noch nicht aber ein Entwicker nutzt es trotzdem dann wird es ohne Codeänderung auch bei B Funktionieren sobald auch dort dieses Feature unterstützt wird. Aus diesem Grund darf ja nVidia bei dem 2.X Shader nicht alles anbieten was sie eigentlich könnten.

Ich hätte ja eigentlich nichts gegen die Extensions wenn sie nicht derart inflationär eingesetzt würden. Die IHV nutzen diese Möglichkeit ganz eindeutig um sich nicht einig werden zu müssen.

[zeckensack]

Original geschrieben von Demirug
Da spielt es ja auch primär keine Rolle weil der Compiler hier auf meinen Rechner seinen Dienst tut. Welcher Compiler auf einem anderen Rechner arbeit braucht mich da nicht zu interesieren weil ich nur Code ausliefere der Herstellerneutral ist (läuft auf allen x86 CPUs).Sehe ich leicht anders, in Bezug auf Prozessor-spezifische Optimierungen. Selbst-tunende Software ist doch "state of the art". Das ist die gleiche Art von Polymorphie, die man auch mit OpenGL braucht (... wenn man optimieren will).
Es gibt mehr als genügend die es nicht sind. Es gibt bis heute keine allgemeine Extension um die Pixelshading Funktionen einer DX8 Karte unter OpenGL zu nutzen. Und selbst wenn fehlt da einfach die Plannungssicherheit.Ja, die Shader auf dem DX8-Level sind bekanntermassen nicht einheitlich ansprechbar. Man braucht dafür exakt zwei Pfade, weil es ausser NV20 und R200 sowieso keine relevanten Ziele gibt. Ob das ein KO-Argument sein kann, liegt IMO eher an der persönlichen Präferenz, denn man erhält auch einen echten Mehrwert, in Form von ggü DX8(.1) erhöhten Limits auf NV2x.

Das ist das Paradebeispiel. Andere Beispiele? Aus den meisten anderen Extensions, sofern sie überhaupt sinnvoll einsetzbar sind, wird früher oder später etwas einheitliches. Die weniger sinnvollen verschwinden in der Bedeutungslosigkeit. Das nennt man Evolution.

Beispiele:
1)NPT-Texturen
NV_texture_rectangle war zunächst nur auf NV-Karten verfügbar, später auch bei ATI. Eine einheitliche Variante davon ist dann mit EXT_texture_rectangle entstanden - diese ist 100%ig abwärtskompatibel zur NV-Version. Man muss nur im Init-Code einen String austauschen.
Die ARB-Fassung (ARB_texture_non_power_of_two) ist allgemeiner, und mächtiger gehalten, dh sie ist auf mächtigere HW angewiesen. Wer's nicht braucht, kann weiterhin EXT_tr nutzen.

Das könnte man böswillig "Texture Rectangle 2.0" nennen ;)

2)Geometrie-Buffer
Lange Zeit (seit GL 1.1) nur im Client-Speicher.
NV_vertex_array_range war sehr low-levelig, es konnte in der Form keinen offiziellen Status erlangen.
ATI_vertex_array_object et al war recht komplex und vielseitig, insbesondere wurde hier auf gemischte Streams Wert gelegt. Das Interface war dementsprechend unübersichtlich.

Die evolutionäre Lösung ist ARB_vertex_buffer_object, das mittlerweile wirklich überall verfügbar ist (Riva TNT ahoi!).
Hier braucht man grössere Code-Änderungen, dies sind jedoch allesamt Vereinfachungen (wenn man vorher ATI_vao oder NV_var genutzt hat).

3)Point sprites
NV_point_sprite, Erstfassung mit spezieller Unterstützung für NV20-Eigenheiten. Diese wurden entfernt für ARB_point_sprite.

99% alles NV_ps-Codes lässt sich ohne Änderungen trivial auf die ARB-Variante umschreiben (anderer Namens-String, andere Funktionsnamen).

4)Vertex shader
ATI_vertex_shader, NV_vertex_program[2], EXT_vertex_shader. => ARB_vertex_shader
Ging recht flott. Das Nutzungsmodell ist 100% gleich (Programm wird als String übergeben, der VS wird über glEnable/glDisable an/ausgeschaltet). Die Syntax hat sich dagegen leicht geändert.

Etc. Idr sind Features schon vereinheitlicht, bevor die ersten grossen Projekte, die das brauchen, überhaupt veröffentlicht werden.

Wie gesagt, Parade-Ausnahme sind die NV2x/R200-Pixel Shader.
Davon abgesehen kriegt man mit herstellerspezifischen Extensions nunmal das Maximum aus den Chips heraus. Wenn man dafür keine Zeit hat, und auf die letzten zweieinhalb Features freiwillig verzichten möchte, kann man auch rein mit Core-Features oder (austauschbar) ARB-Extensions schnieke Software produzieren.
Hier meine ich ZB die prä-Shader-Combiner. ARB_texture_env_combine ist gut und wird von den IHVs flächendeckend unterstützt. ATI_texture_env_combine3 ist cool, wenn man die letzten 10% aus Radeons holen will, man kann es aber auch lassen. NV_texture_env_combine4: dito. NV_rc: dito.

Aber: man hat die Wahl, wie man seine Zeit verplempern möchte.
Es gibt einen grossen unterschied zwischen Extensions bei OpenGL und Caps bei DX. Bei den Extensions hat man Narrenfreiheit. Bei den Caps kann man nur im vorgebenen Rahmen arbeiten. Unterstützt also A ein Feature und B noch nicht aber ein Entwicker nutzt es trotzdem dann wird es ohne Codeänderung auch bei B Funktionieren sobald auch dort dieses Feature unterstützt wird. Aus diesem Grund darf ja nVidia bei dem 2.X Shader nicht alles anbieten was sie eigentlich könnten.Ja. Dazu muss unbedingt noch erwähnt werden, dass wenn ein Feature nicht bei der Entwicklung der letzten DX-Spec bereits bekannt war, und auch berücksichtigt wurde, kann man es überhaupt nicht nutzen. OpenGL kann neue Features jederzeit und sofort integrieren.
Ich hätte ja eigentlich nichts gegen die Extensions wenn sie nicht derart inflationär eingesetzt würden. Die IHV nutzen diese Möglichkeit ganz eindeutig um sich nicht einig werden zu müssen. Dazu habe ich vieles bereits weiter oben geschrieben. Du kriegst die neuen Features unter GL sehr schnell, was man durchaus als Vorteil werten kann.
Aus interessanten Features wird immer auch eine ARB-Version. Das "Problem" ist einfach, dass du den Evolutionsprozess bis dahin selbst miterlebst. Du kannst natürlich die Finger von IHV-spezifischen Dingen lassen, aber IMO ist das unklug: man kann früher anfangen, mit dem Zeugs zu experimentieren, und das meiste von dem gelernten kann man später auch auf die ARB-Variante übertragen.

Die neutralen Extensions sind letztlich das Produkt dieser "offenen Beta-Tests", und reifen durch das Feedback aus den "Beta"-Features umso schöner heran.

Du kannst nunmal keine einheitliche Schnittstelle haben, ohne dass irgendjemand einen ersten Vorschlag gemacht hat. Wenn dieser erste Vorschlag sich in umfassenden Feld-Tests bewähren musste, umso besser.

[sth]

Mich kotzt das mit den Hersteller-Extensions auch an. Trotzdem: Bis auf die r200/nv20 PixelShader sind mittlerweile die meisten wichtigen NV- und ATI-Extensions in ARB-Extensions aufgegangen, welche von beiden Herstellern unterstützt werden.

Siehe z.B. GL_ARB_FRAGMENT_PROGRAM, GL_ARB_VERTEX_PROGRAM.

Eine ARB-Extension für die r200/nv20 PixelShader wäre ein Traum, den ich aber mittlerweile zu träumen aufgegeben habe.

An sich habe ich mit den Extensions allgemein kein großes Problem. Unter Linux kann man die - dank aktuellerer GL-Libs - auch recht einfach verwenden.

Was mich ärgert ist die Einbindung der Extensions unter Windows (das bekanntlich by default immernoch nur mit OpenGL 1.1 daherkommt): Ich sag' nur PFNGLCLIENTACTIVETEXTUREARBPROC :bonk:

[zeckensack]

Original geschrieben von sth
Was mich ärgert ist die Einbindung der Extensions unter Windows (das bekanntlich by default immernoch nur mit OpenGL 1.1 daherkommt): Ich sag' nur PFNGLCLIENTACTIVETEXTUREARBPROC :bonk: Kann man auch anders machen, ist reine Fleissarbeit. Wen dir das alles zu viel ist: nimm Glee (http://www.elf-stone.com/index.php).

[Demirug]

Was haben jetzt Befehlscodeerweiterung der CPUs mit irgendwelchen Erweiterungen in den Compilern zu tun?

Was Dinge wie SSE usw. angeht haben wir doch eine ganz andere Situation. Das einzige mal das AMD sich getraut hat was anderes als Intel zu machen war 3DNow. Inzwischen baut man dort schön die Erweiterungen von Intel nach. Aber selbst wenn nicht ist das nur relevant wenn man die Erweiterungen direkt mit Assembler benutzt. Lässt man einen Compiler (z.B. VectorC) diesen Job machen oder kauft sich eine entsprechen Bibliothek zu hat man da auch keinen Ärger mehr mit. Man schreibt sein Programm und kompiliert es einfach für die Unterschiedlichen Plattformen.


Ich weiss nicht ob es die Besitzer einer Parhelia so toll finden das du ihnen den relevant Status absprichst. Es ist richtig das sich kaum ein Entwickler mit dieser Karte auseinader setzt. Alles ausser ATI und nV wird ignoriert. Dieses Verhalten macht geraden den kleinen Herstellern das Leben zusätzlich schwer. Auf die Extensions der beiden grossen können sie in der Regel nicht aufspringen weil das ihere Hardware nicht hergibt und eine eigene würde niemand berücksichtigen. Bei DX haben sie etwas an dem sie sich festhalten können weil schon viel früher feststeht was verlang wird.

Es ist schön das du hier eine Reihe von Beispielen aufführst die Beweisen wie aus einer Herstellerextension eine allgemeine wurde. Allerdings taucht dort für meinen Geschmak viel zu oft das Wort "umschreiben" auf. Umschreiben = Zeit = Geld und Geld ist immer zuwenig da. Natürlich wird vieles Vereinheitlicht vor dem Releasetermin. Aber die Entwicklung fängt ja viel früher an und eine Garantie das es eine Vereinheitlichung geben wird kann niemand zusichern. Diese Unsicherheiten stellen jede Planung von Anfang an auf unsicherer Füsse.

Ich weiss das jetzt gleich das Argument kommt das man auch bei DX jedesmal wenn eine neue Version kommt mit dem umschreiben anfangen muss. Das stimmt ja auch mehr oder minder. Sollte es im Verlauf des Projekts zu einer neuen DX-Version kommen muss man ja aber nicht darauf anspringen. Tut man es aber weiss man genau was auf einen zu kommt. Bei OpenGL haben ich das Problem mit jeder neuen Karte die neue Extensions mitbringt.

Es wurde aufgeführt das man für die beiden DX8 Karten NV2X und R2XX zwei zusätzliche Code-Pfade braucht. Richtig. Dann ist aber auch noch mindestens einer für die Vorgänger und einer für die Nachfolger fällig. Unter DX brauche ich genau 2 Pfade wenn ich das Effektmangment selber mache (Fixed und Shader) und einen wenn ich das Effektmangemnet von D3DX benutzte. Der Rest kann alles in die Designtools verlagert werden. Ich bewege mich also vom Codedriven Model zu einem Konfigurations gesteuerten Model. Was die Entwicklungszeiten massiv beschleunigt. Natürlich werden IHV Spezifische Funktionen in glslang auch im Konfigurationsbereich laden und deswegen die Situation auch im vergleich zu "vollwertigen" Extensions entschärfen. Aber die Planungsunsicherheit bleibt.

Das man nur das nutzen kann was vorgesehen wurde ist natürlich ein Tot den man mit DX sterben muss. Im Verhältniss zu den Vorteilen halte ich das aber für einen kleinen Preis.

[Chris Lux]

ich glaube wir kommen ein wenig vom eigentlichen thema ab. es gin doch darum, dass für GLslang auch extensions geplant werden.

ich kann das wirklich nicht gut finden, da man so auch wieder verschiedene shader programme an den fähigkeiten ausrichten muss. zum beispiel die texture rects. sind sie verfügbar kann man sie im shader nutzen wenn nicht pech und ein neuer shader muss her (beispiel offsetberechnungen).

im grunde finde ich extensions toll, um mit neuen features rumspielen zu können. aber bei glslang sehe ich dann leider, dass die sprache sehr schnell mit zu vielen (sinnvollen oder weniger sinnvollen) erweiterungen zerstört wird, im sinne ihrer eigentlichen aufgabe eine unabhängige shaderspreche darzustellen.

[Chris Lux]

Original geschrieben von zeckensack
Beispiele:
1)NPT-Texturen
NV_texture_rectangle war zunächst nur auf NV-Karten verfügbar, später auch bei ATI. Eine einheitliche Variante davon ist dann mit EXT_texture_rectangle entstanden - diese ist 100%ig abwärtskompatibel zur NV-Version. Man muss nur im Init-Code einen String austauschen.
Die ARB-Fassung (ARB_texture_non_power_of_two) ist allgemeiner, und mächtiger gehalten, dh sie ist auf mächtigere HW angewiesen. Wer's nicht braucht, kann weiterhin EXT_tr nutzen.

Das könnte man böswillig "Texture Rectangle 2.0" nennen ;)


frage: in meinem detonator 53.03 un meiner gffx wird nur die nv_tr angegeben. die beiden anderen sind zwar scheinbar schon offizielle, aber welcher treiber (ati oder nv) unterstütz sie?

[Crushinator]

Original geschrieben von Hans Ohlo
frage: in meinem detonator 53.03 un meiner gffx wird nur die nv_tr angegeben. die beiden anderen sind zwar scheinbar schon offizielle, aber welcher treiber (ati oder nv) unterstütz sie? CAT 3.10

[zeckensack]

Original geschrieben von Hans Ohlo
ich glaube wir kommen ein wenig vom eigentlichen thema ab. es gin doch darum, dass für GLslang auch extensions geplant werden.Nein und ja, IMO. Ich denke die Debatte zum Thema "Extensions" gehört schon zum Thema.
ich kann das wirklich nicht gut finden, da man so auch wieder verschiedene shader programme an den fähigkeiten ausrichten muss. zum beispiel die texture rects. sind sie verfügbar kann man sie im shader nutzen wenn nicht pech und ein neuer shader muss her (beispiel offsetberechnungen).Wenn ein Shader ohne RECTs möglich ist, sollte man ihn auch ohne RECTs implementieren. RECTs sind sowieso nur für Fullscreen-Effekte mit exaktem Pixel/Texel-Verhältnis interessant, um Speicher zu sparen.
im grunde finde ich extensions toll, um mit neuen features rumspielen zu können. aber bei glslang sehe ich dann leider, dass die sprache sehr schnell mit zu vielen (sinnvollen oder weniger sinnvollen) erweiterungen zerstört wird, im sinne ihrer eigentlichen aufgabe eine unabhängige shaderspreche darzustellen.Einerseits kann man den IHVs nicht verbieten, Extensions zu kreieren. Andererseits wird niemand dazu gezwungen, Extensions zu benutzen.
*schulterzuck*

[Coda]

Was ist das für ein Program crushinator?

[Chris Lux]

Original geschrieben von zeckensack
Wenn ein Shader ohne RECTs möglich ist, sollte man ihn auch ohne RECTs implementieren. RECTs sind sowieso nur für Fullscreen-Effekte mit exaktem Pixel/Texel-Verhältnis interessant, um Speicher zu sparen.

japp genau auf solche shader wollte ich hinaus.

Original geschrieben von zeckensack
Einerseits kann man den IHVs nicht verbieten, Extensions zu kreieren. Andererseits wird niemand dazu gezwungen, Extensions zu benutzen.
*schulterzuck*
jap, an sich ist es ja nicht schlecht, auch in hinsicht auf die meist folgenden standard extensions. aber bei glslang sollte man lieber den weg gehen die sprache sehr mächtig zu machen und dem IHV es zu überlassen wie er es intern (in seinem compiler) umsetzt.

aber im grunde ist es eh hin wie her. wie du schon sagst, ob man es nutzt oder nicht is jedem selbst überlassen. und wer bei ogl an sich extensions nutzt wird sie auch bei glslang begrüssen/nutzen.

im grunde könnte man auch bei d3d nörgeln: man muss testen welche caps vorhanden sind bevor man sie nutzen kann, genauso wie man testen muss welche extensions da sind (mal die initialisierung aussen vor gelassen), und muss dann auch so verschiedene renderpfade coden.

[Chris Lux]

Original geschrieben von Coda
Was ist das für ein Program crushinator?

OpenGL Extension Viewer

http://www.realtech-vr.com/glview/index.html#Download

[zeckensack]

Original geschrieben von Demirug
Was haben jetzt Befehlscodeerweiterung der CPUs mit irgendwelchen Erweiterungen in den Compilern zu tun?Compiler-Erweiterungen meinte ich auch nicht, sondern SSE, SSE2, 3DNow und x87-"Pfade" im Code (wobei bis auf den letzten alle optional sind).

Das hat IMO durchaus eine gewisse Ähnlichkeit zu GL-Extensions.
Ich weiss nicht ob es die Besitzer einer Parhelia so toll finden das du ihnen den relevant Status absprichst. Es ist richtig das sich kaum ein Entwickler mit dieser Karte auseinader setzt. Alles ausser ATI und nV wird ignoriert. Dieses Verhalten macht geraden den kleinen Herstellern das Leben zusätzlich schwer. Auf die Extensions der beiden grossen können sie in der Regel nicht aufspringen weil das ihere Hardware nicht hergibt und eine eigene würde niemand berücksichtigen. Bei DX haben sie etwas an dem sie sich festhalten können weil schon viel früher feststeht was verlang wird.Matrox ist selbst schuld. Sie kennen ihre PS-Hardware, sie wären durchaus in der Lage, sie irgendwie unter GL voll verfügbar zu machen. Ob sie sich jetzt dabei an irgendeinem anderen Nutzungsmodell orientieren sollen, oder etwas komplett neues bringen, ist eine rein akademische Debatte: sie haben bisher überhaupt nichts gemacht.

Matrox' GL-Treiber stehen im Ruf, ausser Quake-Engines nichts zustande zu bringen. So einfach ist das. Solange sich das nicht ändert, wird auch kein Entwickler ernsthaft damit arbeiten wollen. Ich bin aber halbwegs überzeugt davon, dass die Treiber wesentlich besser werden, sobald Doom 3 zur Marktreife kommt ...
Es ist schön das du hier eine Reihe von Beispielen aufführst die Beweisen wie aus einer Herstellerextension eine allgemeine wurde. Allerdings taucht dort für meinen Geschmak viel zu oft das Wort "umschreiben" auf. Umschreiben = Zeit = Geld und Geld ist immer zuwenig da.Init-Code (stark gekürzt):
//header

bool grab_extensions();

#define FP_DECLARE(name,ret,parms) typedef ret (APIENTRY *FP_##name)parms;\
extern FP_##name name

#define FP_DEFINE(name) FP_##name name=NULL

FP_DECLARE(glDrawRangeElementsEXT,void,(GLenum,GLuint,GLuint,
GLsizei,GLenum,const GLvoid*));

struct GL_caps
{
bool arb_fragment_program;
bool ati_fragment_shader;
bool vbo; //GL_ARB_vertex_buffer_object
int nv_register_combiners; //number of general combiners, 0 if not supported
bool atix_tec3; //GL_ATI(X)_texture_env_combine3 (R100)
bool rectangle_textures; //GL_NV_texture_rectangle or GL_EXT_texture_rectangle
bool arb_tec; //GL_ARB_texture_env_combine
};

extern GL_caps gl_caps;
//modul
#include ...

#define GL_FP_GRAB(name) (name=(FP_##name)wglGetProcAddress(#name))

GL_caps gl_caps;

FP_DEFINE(glDrawRangeElementsEXT);

void APIENTRY
replacement_glDrawRangeElements(GLenum mode,GLuint start,GLuint end,
GLsizei count,GLenum type,const GLvoid *indices)
{
glDrawElements(mode,count,type,indices);
}

bool
grab_extensions()
{
memset(&gl_caps,0,sizeof(gl_caps));
<...>
if (is_supported("GL_EXT_draw_range_elements")&&
GL_FP_GRAB(glDrawRangeElementsEXT))
{
// gl_caps.dre=true; //transparently emulated
}
else
{
glDrawRangeElementsEXT=replacement_glDrawRangeElements;
}

if (is_supported("GL_NV_texture_rectangle")||
is_supported("GL_EXT_texture_rectangle"))
{
gl_caps.rectangle_textures=true;
}
<...>
return(true);
}Dreieinhalb Gründe für diesen Code-Auszug:
1)Die GL_caps-Struktur zeigt mein Nutzungsmodell. Ich benutze auch Caps, dh ich wähle mir das maximale Featureset im Vorfeld aus, so wie DX das auch tut. Betonung auf: ich wähle.
2)Einige Extensions können - wenn sie nicht vorhanden sind - so gewrappt werden, dass der Code, der sie letztlich benutzt, nichts davon merkt. Das betrifft vornehmlich Features zur Steigerung der Effizienz (hier EXT_draw_range_elements, ARB_window_pos, ARB_vertex_buffer_object, etc).
3)NV_texture_rectangle und EXT_texture_rectangle müssen zwar beide erkannt werden, aber sie werden gleich behandelt. Der nutzende Code ist exakt gleich (diese beiden Extensions führen nur numerische Tokens ein, und die sind bei beiden gleich).
3b)dieses Verfahren lässt sich ähnlich zu Fall 2 auch auf funktionale Extensions anwenden. Da ich sowieso Funktionszeiger holen muss, kann ich die auch auf andersnamige Extensions umbiegen.

Natürlich wird vieles Vereinheitlicht vor dem Releasetermin. Aber die Entwicklung fängt ja viel früher an und eine Garantie das es eine Vereinheitlichung geben wird kann niemand zusichern. Diese Unsicherheiten stellen jede Planung von Anfang an auf unsicherer Füsse.In Bezug auf Shader hast du wohl recht, im bereits eingeräumten Rahmen. Wie schlimm das nun ist, ist offenbar Ansichtssache, und ich respektiere durchaus deine Meinung. Ich wollte nur auf den "Wahn" etwas entgegnen, damit er nicht so unkommentiert dasteht :)

<...>
Bei OpenGL haben ich das Problem mit jeder neuen Karte die neue Extensions mitbringt.Du kannst neue Extensions auch einfach ignorieren, so wie du eine neue DX-Runtime (mit grösserem Feature-Support) ignorieren kannst.
<...>
Unter DX brauche ich genau 2 Pfade wenn ich das Effektmangment selber mache (Fixed und Shader) und einen wenn ich das Effektmangemnet von D3DX benutzte. Der Rest kann alles in die Designtools verlagert werden. Ich bewege mich also vom Codedriven Model zu einem Konfigurations gesteuerten Model.Unter GL muss man das mit eigenen LIBs erschlagen, in Kombination mit ein bisserl Meta-Programmierung. Das funktioniert natürlich ganz anders, ist aber durchaus in erträglicher Zeit machbar.
Wie bereits an anderer Stelle erwähnt, einen kleinen Effekt-Parser für ARB_fragment_program hatte ich in 4 Stunden geschrieben, und nach weiteren 4 Stunden fertig(TM).
Der nutzende Code kann bei diesem Modell auch nicht mehr erkennen, auf welcher Zielarchitektur er läuft. Ist alles transparent.
DX bietet hier den Vorteil des fix-und-fertigen Frameworks. Das ARB kommt IMO auch langsam auf den Trichter, dass mächtigere "utility toolkits" wünschenswert sind. Vielleicht kommt da noch was.

[Demirug]

zeckensack, ich bezog mich auf Compiler erweiterungen deswegen war ich verwirrt wieso du plötzlich mit SSE gekommen bist. Aber wie gesagt gibt es inzwischen ja auch dafür Compiler die normalen C/C++ Code dafür optimieren.

Matrox hat eine Extension im Treiber nur eben keine Dokumenatation dafür.

Dein Codebeispiel zeigt mir das du letzten endes nichts anderes machst als dir Funktional ein DX nachzuprogrammieren. OK du hast den Vorteil dein Featureset selbst zu wählen. Im Gegenzug kannst aber nicht den gleichen Druck wie MS ausüben das eine Vereinheitlichung von neuen Features statfindet. Es ist eben eindeutig die Wahl zwischen Freiheit (OpenGL) und Arbeitserleichterung (DX). Das ich ein fauler Hund bin habe ich ja schon erwähnt. Ich habe genügend Ärger mit dem Front-End so das ich derzeit wenigsten ein einheitliches Backend haben möchte. Das ist aber eine Entscheidung die jeder selbst treffen muss. Wie du allerdings treffend festgestellt hast hat sich das ARB bisher zu wenig um das wohl der Entwickler gekümmert.

[Crushinator]

*Thread ausgrab*

ATi hat scheinbar ganz heimlich das nachgeschoben, was noch fehlte. ;) (CAT 4.2)

[DrumDub]

crushinator

jupp. wird jetzt alles unterstützt mit dem cat 4.2.

haste den redering test mal gemacht?

[misterh]

hier von mir :D

[DrumDub]

Original geschrieben von misterh
hier von mir :D

net schlecht... bei mir isses nen xp2000 mit ner 9700np@390/300 gewesen.

übrings nen kleiner tipp, was das anhängen von screenshots angeht: besser als gif abspeichern, wenn es sich um screenshots mit wenig farben handelt.

[Coda]

Was ist das für nen Program? :)
EDIT: Ah jetzt sieht man's ja Oo

[Crushinator]

Original geschrieben von DrumDub
(...)
haste den redering test mal gemacht? :o Jetzt, wo Du's erwähnst, fällt mir ein, daß ich's noch nie ausprobiert habe.

Ver. FPS
-----------------
1.1 1964
1.2 1972
1.3 1694
1.4 1195
1.5 1142
2.0 977

R97Pro@default (325/310) auf XP2000/KT333A/DDR266CL2
Win98SE, Auflösung und Optionen wie DrumDub.

[DrumDub]

hmm... der ramtakt macht hier wohl einiges aus.

xp2000@1725, 9700np@390/310

[Crushinator]

:kratz2: Wieso diesmal in 16-Bit?

[DrumDub]

Original geschrieben von crushinator
:kratz2: Wieso diesmal in 16-Bit?

uppss... moment.


ich raff nicht, wieso deine 1.1 texturing-werte soviel höher sind bei gleichem takt. sehr merkwürdig.

[marco42]

Also ich benutze eigentlich nur ARB extensions. Ich spiele zwar auch gern mit den NV extensions herum, aber fuer die eigentliche Implementierung benutze ich immer die ARB extensions.

Wenn man die ARB notes liesst, sieht man meistens schon wo die Richtung hingeht. Das hat auch den Vorteil, dass es stabiler laeuft, da die Treiber dann einfach mehr mature sind.

Ich hoffe auch, das weder DX noch OpenGL eingeht, ansonsten machen entwerden MS nichts mehr(siehe Internet Explorer) oder die Hersteller was sie wollen.

Dazu sollte ich wohl auch sagen, dass ich meine momentanes Projekt groesstenteils in Python reimplementiert habe, da es sich darin einfach schneller entwickeln laesst und es nur ein paar stellen gibt, wo C gefragt ist.

Der groesste Vorteil liegt fuer mich aber in der Platformunabhaenigkeit. Ich benutze einfach kein Windows, aber es sollte auch darauf laufen.

Die Wahl von OpenGL und DX haengt also IMHO von den Praeferenzen ab.

Die einige Erweiterung waren auch urspruenglich in der GLSlang drin, wuerden dann aber wieder herausgeworfen. Die keywords sind auf jeden Fall reserviert.

Half und Short (sizeof(x) >= 16 bit)als Erweiterung der Datentypen waere wirklich nett.

Aber ich gebe dir Recht, sie sollten Herstellerextensions mehr mit X makieren, wie SGI das gemacht hat, also NVX, ATIX etc. um damit zum Ausdruck zu bringen, dass es doch eher beta code und/oder das Interface noch optimiert werden kann.

[Crushinator]

Original geschrieben von DrumDub
ich raff nicht, wieso deine 1.1 texturing-werte soviel höher sind bei gleichem takt. sehr merkwürdig. :gruebel: "AGP FastWrite" ist bei mir immer an und bei VRAM-Caching ist USWC anstatt UC aktiviert, und zwar weil das A7V333 im Turbo-Mode u.A. genau diese Einstellungen vornimmt. Könnte es daran liegen? :ratlos:

Unter Win2K hab' ich sogar nur CAT 3.9, un da sieht das Ergebnis nicht viel anders aus:

[del_4901]

Original geschrieben von Demirug
ARB Meeting Node Spetember 10 (http://www.opengl.org/about/arb/notes/meeting_note_2003-09-10.html)



Was soll das nun schon wieder?

Für was gibt es eine einheitliche Sprache wenn dann doch wieder jeder seine eigene Funktionen dazu bauen darf?

Bei einem "normalen" Compiler mag das ja gerade noch angehen aber doch nicht bitte bei etwas was auf jeden Fall portabel sind soll. OK, man müsste die Hersteller spezifischen Funktionen ja nicht nutzen aber aleine die Möglichkeit dazu nimmt von den IHVs den Druck sich einig zu werden. Zudem ist mir auch noch nicht ganz klar wie das mit dem Abfragen ob eine Funktion nun vorhanden ist oder nicht ablaufen soll. Etwa über den Extensions-String?

Bei solchen Ideen brauchen sie sich jedenfalls nicht zu wundern warum sich immer weniger Entwickler für OpenGL begeistern können.
Öhm, vielleicht hat ja auch das Stichwort "P10" da seine Finger im Spiel. Creative ist mächtig, und 3dLabs sitzt schon lange in der Ogl Fraktion.

[Demirug]

Ich habe es ja geahnt.

nVidia konnte es natürlich nicht lassen und hat glslang mit ein paar Extensions erweitert.

http://download.nvidia.com/developer/presentations/GDC_2004/gdc_2004_NV_GLSL.pdf

[Chris Lux]

ich würd nicht sagen glslang erweitert, sondern ehr den cg syntax glslang tauglich gemacht ;)

aber mal ehrlich, glslang braucht noch ein paar erweiterungen, die meiner meinung nach von anfang an drinnen gewesen sein sollten (nur als beispiel die sachen mit den state matrizen, was da die ARB_vertex_program an möglichkeiten bietet und die vier, fünf sachen die da bei glslang möglich sind). auch wäre es schön, wenn die API noch erweiterungen erfährt, zum beispiel gefällt mir die cg-runtime sehr gut. diese hat viele möglichkeiten informationen über die parameter zu erfahren usw., die komplett fehlen bei glslang. auch die handhabung der texturen ist bei cg um einiges einfacher, da an einen sampler von aussen einfach nur die id des texture objekts gebunden wird und man sich weiter um nichts kümmern muss/braucht (man kann schon alles von hand machen, aber wozu, wenn einem die runtime die arbeit abnimmt). im gegensatz dazu muss bei glslang angegeben werden an welche texture unit man die entsprechende textur bindet und diese dann auch noch vorher an die jeweilige unit binden (mit einem gewissen) mehraufwand, der wieder fehler verursachen kann.

IMO sollte die glslang spec nocheinmal gründlich überarbeitet werden, denn was da zu sehen ist sieht sehr nach einem schnellschuss aus um nicht zugeben zu müssen, dass cg doch 'ok' ist ;).


p.s. das soll kein flamewar werden, ich wollte nur ein paar punkte aufführen, die meiner meinung nach doch recht seltsam gelöst sind.

[Demirug]

Original geschrieben von Hans Ohlo
ich würd nicht sagen glslang erweitert, sondern ehr den cg syntax glslang tauglich gemacht ;)

Ja, man kann damit anstelle von glslang Code auch einfach Cg Code benutzten. Sie haben aber auch zu glslang neue Datentypen und Funktionen hinzugefügt.

aber mal ehrlich, glslang braucht noch ein paar erweiterungen, die meiner meinung nach von anfang an drinnen gewesen sein sollten (nur als beispiel die sachen mit den state matrizen, was da die ARB_vertex_program an möglichkeiten bietet und die vier, fünf sachen die da bei glslang möglich sind). auch wäre es schön, wenn die API noch erweiterungen erfährt, zum beispiel gefällt mir die cg-runtime sehr gut. diese hat viele möglichkeiten informationen über die parameter zu erfahren usw., die komplett fehlen bei glslang. auch die handhabung der texturen ist bei cg um einiges einfacher, da an einen sampler von aussen einfach nur die id des texture objekts gebunden wird und man sich weiter um nichts kümmern muss/braucht (man kann schon alles von hand machen, aber wozu, wenn einem die runtime die arbeit abnimmt). im gegensatz dazu muss bei glslang angegeben werden an welche texture unit man die entsprechende textur bindet und diese dann auch noch vorher an die jeweilige unit binden (mit einem gewissen) mehraufwand, der wieder fehler verursachen kann.

Ja, Ein Framework welcher die Arbeit erleichtert war schon immer eine Schwäche von OpenGL. Sicher gibt es da einige die man benutzten kann aber es wäre IMHO ein Schritt in die richtige Richtung von das ARB mal einen standard Framework definiert.

[Chris Lux]

Original geschrieben von Demirug
Ja, man kann damit anstelle von glslang Code auch einfach Cg Code benutzten. Sie haben aber auch zu glslang neue Datentypen und Funktionen hinzugefügt.


das meinte ich ;), die datentypen sind IMO schon eine feine sache (gerade wenn man für nvidia hardware optimieren möchte). ich sage nur EXT_cg_shader ;)


Ja, Ein Framework welcher die Arbeit erleichtert war schon immer eine Schwäche von OpenGL. Sicher gibt es da einige die man benutzten kann aber es wäre IMHO ein Schritt in die richtige Richtung von das ARB mal einen standard Framework definiert.

full ack.
ich muss aber sagen, die GDC slides über die neuen extensions und möglichkeiten der kommenden nv4x reihe machen mir jetzt schon spass. interessant finde ich die option sachen für die arb extensions. würde mich interessieren was passiert, wenn man versucht einen an sich einfachen shader mit einer solchen option auf einer hardware, die diese extension nicht unterstützt, zu benutzen.

ich hoffe nur, dass sie cg weiterentwickeln oder sich das arb cg und dessen ideen nochmal genauer anschaut.

[marco42]

Original geschrieben von Demirug
Ich habe es ja geahnt.

nVidia konnte es natürlich nicht lassen und hat glslang mit ein paar Extensions erweitert.

http://download.nvidia.com/developer/presentations/GDC_2004/gdc_2004_NV_GLSL.pdf

Muss man ja nicht benutzten. Sie sagen leider nichts ueber noise. :-(

[marco42]

Original geschrieben von Hans Ohlo
auch die handhabung der texturen ist bei cg um einiges einfacher, da an einen sampler von aussen einfach nur die id des texture objekts gebunden wird und man sich weiter um nichts kümmern muss/braucht (man kann schon alles von hand machen, aber wozu, wenn einem die runtime die arbeit abnimmt). im gegensatz dazu muss bei glslang angegeben werden an welche texture unit man die entsprechende textur bindet und diese dann auch noch vorher an die jeweilige unit binden (mit einem gewissen) mehraufwand, der wieder fehler verursachen kann.


So schlimm ist das auch nicht, sie schreiben ja auch, dass sie das noch aendern wollen. Sie haben mit der Zeit ja auch einige Sachen herausgeschmissen. Besser so, als wieder sehr viel alten Muell mit herum zu schlaeppen.

Was mich interessieren wuerde, ist das neue Object System. Werden sie die VBO, Texture Object etc auf das neue System anpassen oder lassen belassen sie es, wie es ist.

[Chris Lux]

Original geschrieben von marco42
So schlimm ist das auch nicht, sie schreiben ja auch, dass sie das noch aendern wollen. Sie haben mit der Zeit ja auch einige Sachen herausgeschmissen. Besser so, als wieder sehr viel alten Muell mit herum zu schlaeppen.

naja das is so neu, da war kaum müll dabei. zb texture rectangles sind raus, warum fragt man sich da (und ARB_texture_non_power_of_two ist leider nocht nicht so weit verbreitet).

[marco42]

Original geschrieben von Hans Ohlo
naja das is so neu, da war kaum müll dabei. zb texture rectangles sind raus, warum fragt man sich da (und ARB_texture_non_power_of_two ist leider nocht nicht so weit verbreitet).

Sind halt noch nicht im Core. Was mir wirklich fehlt sind die Moeglichkeiten, die Ueber buffer bieten. Pbuffer sind einfach zu kompliziert und dann auch noch unportable. Render To Texture gibt es nur unter Windows. Naja, zum Glueck gibt es ja glConvolutionFilter jetzt in Hardware. Und glCopyTexImage2D kostet nicht die Welt. Schoener waeren Ueberbuffer aber schon.

[Corrail]

ch habe es ja geahnt.

nVidia konnte es natürlich nicht lassen und hat glslang mit ein paar Extensions erweitert.

http://download.nvidia.com/develope...004_NV_GLSL.pdf


Dies wird gerade bei opengl.org heftig diskutiert. Es sind schon die erste Probleme damit aufgetreten...


(und ARB_texture_non_power_of_two ist leider nocht nicht so weit verbreitet)


Das lieg daran, das derzeit keine Grafikkarte ARB_texture_npo2 unterstützt. Diese Extension schreibt einige Sachen vor, die heutige Hardware noch nicht kann, zum Beispiel mip-mapping. (was bei NV/EXT_texture_rectangle nicht verlangt wird)


Was mir wirklich fehlt sind die Moeglichkeiten, die Ueber buffer bieten.


So, wie die letzten Entwicklungen aber ausschauen, wirds mit den Ueber buffer nichts... Find ich schade, die konnten echt einiges! Zur Zeit stehts ja VBO/PBO/EXT_render_target gegen Suber/Ueber buffer. Bin gespannt was da rauskommt, würd mich aber über die Super buffer echt freuen.

[marco42]

Original geschrieben von Corrail
So, wie die letzten Entwicklungen aber ausschauen, wirds mit den Ueber buffer nichts... Find ich schade, die konnten echt einiges! Zur Zeit stehts ja VBO/PBO/EXT_render_target gegen Suber/Ueber buffer. Bin gespannt was da rauskommt, würd mich aber über die Super buffer echt freuen.

VBO/PBO/EXT_render_target sehen nicht schlecht aus, alle Dinge die ich brauche, kann ich damit machen. Erstmal Zeit, Ueberbuffer wirklich gut zu machen.

[Corrail]

Original geschrieben von marco42
VBO/PBO/EXT_render_target sehen nicht schlecht aus, alle Dinge die ich brauche, kann ich damit machen. Erstmal Zeit, Ueberbuffer wirklich gut zu machen.

Stimmt, vorläufig wäre VBO/PBO/EXT_render_target vollkommen ausreichend, wenn da noch eine Zusatz-Extension für MRT dazu käme (ist sicher leicht mit EXT_render_target zu verbinden, z.B. ATI_draw_buffers). Aber für die Zukunft hätte ich schon gerne super buffers... Würde nur ungern auf die verzichten.

[Gast]

Original geschrieben von Corrail
Stimmt, vorläufig wäre VBO/PBO/EXT_render_target vollkommen ausreichend, wenn da noch eine Zusatz-Extension für MRT dazu käme (ist sicher leicht mit EXT_render_target zu verbinden, z.B. ATI_draw_buffers). Aber für die Zukunft hätte ich schon gerne super buffers... Würde nur ungern auf die verzichten.

Schauen wir mal. Mich interessiert erst mal eine hardware noise Implementierung. Ich habe langsam das Gefuehl OpenGL hat die Hardware wieder ueberholt. Das Gefuehl hatte ich schon seit der Infinit Reality nicht mehr.

[Xmas]

Nach den letzten Äußerungen von 3DLabs gehe ich von HW-Noise im P20 aus...

[marco42]

Original geschrieben von Xmas
Nach den letzten Äußerungen von 3DLabs gehe ich von HW-Noise im P20 aus...

Bloss wann kommt der und zu welchen Preisen.

[Corrail]

ATI hat nun auch die GDC 2004 Presentationen zu OpenGL gepostet:
http://www.ati.com/developer/techpapers.html#GDC04

So wies ausschaut, sind die Super-Buffer doch wieder im Rennen! ;D

[Chris Lux]

Original geschrieben von Corrail
ATI hat nun auch die GDC 2004 Presentationen zu OpenGL gepostet:
http://www.ati.com/developer/techpapers.html#GDC04

So wies ausschaut, sind die Super-Buffer doch wieder im Rennen! ;D

uh nice ;O)
jez noch GLSlang klären und GL2 kann kommen.

[Xmas]

Original geschrieben von Xmas
Nach den letzten Äußerungen von 3DLabs gehe ich von HW-Noise im P20 aus...
Wohl doch nicht... schade.