Archiv verlassen und diese Seite im Standarddesign anzeigen : OpenGL: Neue ARB Extensions
Corrail
2004-10-29, 19:30:19
Hi all!
Nach langem langem Warten sind nun endlich neue ARB Extensions online. Und zwar handelt es sich um die Floating Point Format Extensions. In einigen wird sogar Interaktion mit EXT_framebuffer_object erwähnt.... ;)
http://oss.sgi.com/projects/ogl-sample/registry/ARB/color_buffer_float.txt
http://oss.sgi.com/projects/ogl-sample/registry/ARB/half_float_pixel.txt
http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_float.txt
Sehr geil. Aber ARB_render_texture (ohne WGL) wär auch mal angebracht.
Corrail
2004-10-29, 23:30:16
Sehr geil. Aber ARB_render_texture (ohne WGL) wär auch mal angebracht.
Das wird mit EXT_framebuffer_object möglich sein. Hoffen wir, dass es bald kommt!
Uber buffers wurden ja glaube ich abgelehnt, weißt du da auch was genaueres?
Corrail
2004-10-29, 23:55:53
Uber buffers wurden ja glaube ich abgelehnt, weißt du da auch was genaueres?
Ja, die Superbuffer (Uber Buffer) Extension wurde vom ARB abgelehnt. Danach hat die Workgroup was ich weiß den Auftrag bekommen eine einfache Render-To-Texture Extension zu erstellen. EXT_framebuffer_object ist das Resultat daraus.
Die Superbuffer Extension wurde aber nicht ganz verworfen. Bilde mir ein mal irgendwo gelesen zu haben dass sie es für später mal im Core haben wollen. OpenGL 3.0 oder so. In wieweit das stimmt weiß ich aber nicht.
Das wäre mal wieder was gewesen wo OpenGL gegen D3D punkten können hätte. Aber irgendwie is das ARB manchmal komisch.
Corrail
2004-10-30, 01:03:19
Naja, Superbuffer wäre schon nett gewesen, da geb ich dir recht. Aber ich versteh auch warum es sich nicht durchgesetzt hat. Die API war einfach zu überladen. Man hat versucht zu viel auf einmal zu lösen. Außerdem wurde ein Teil von dem was Superbuffer gefordert hätte noch gar nicht von den Grafikkarten unterstützt.
Demirug
2004-10-30, 08:43:50
Wenn es mal WGF gibt bekommt OpenGL auch sicher seine Superbuffers. Dann ist Hardware die das kann zwingend.
Wenn die Änderungen bei 2.0 für eine neue Versionsnummer reichen, dann reichen die Superbuffer auch als Begründung für 3.0 ;)
Ich versteh aber nicht ganz warum man in dem Bereich nicht mal MS nicht mal einen Schritt voraus sein will....
Naja sollen sie sich erstmal um ordentliche Extensions für R2T usw kümmern.
Wie sieht eigentlich mit einer GI-Extension aus? Demi hatte zwar mal gesagt, dass NV nicht vorhat eine zu bringen, aber im SM3 Unleashed PDF von NV wird eine angekündigt.
Corrail
2004-10-30, 12:08:37
GI = Geomatry Instancing?
AFAIK soll das bei OpenGL nicht so wichtig sein wie in DirectX. Im OpenGL Forum diskutieren sie da in (einem vielleicht unpassenden Thread) darüber:
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011406;p=2
Beginnend bei zweiten Post von unten
Wenn es mal WGF gibt bekommt OpenGL auch sicher seine Superbuffers. Dann ist Hardware die das kann zwingend.
Ja, das mag schon stimmen. Aber das ARB ist nun einen anderen Weg gegangen: VBO, PBO & EXT_framebuffer_object und nicht Superbuffer. Dann gäbe es wieder 2 Möglichkeiten ein und das selbe zu tun. Das ist jetzt schon einer DER Kritikpunkte an OpenGL. Ich weiß nicht ob das ARB diesen Weg gehen will/wird und Superbuffer auch noch in den Core zu bringen.
GI = Geomatry Instancing?
AFAIK soll das bei OpenGL nicht so wichtig sein wie in DirectX. Im OpenGL Forum diskutieren sie da in (einem vielleicht unpassenden Thread) darüber:
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=011406;p=2
Beginnend bei zweiten Post von unten
Weniger wichtig ist aber nicht unnütz.
Man könnte da wohl schon noch einiges an Geschwindigkeit rausschlagen mit Hardwareunterstützung.
Früher wurden die Features immer zuerst von OpenGL unterstützt. Heute heissts wenn DX das kann kriegt OGL das bestimmt auch bald ;(
Asmodeus
2004-10-30, 13:01:36
Weniger wichtig ist aber nicht unnütz.
Man könnte da wohl schon noch einiges an Geschwindigkeit rausschlagen mit Hardwareunterstützung.
Früher wurden die Features immer zuerst von OpenGL unterstützt. Heute heissts wenn DX das kann kriegt OGL das bestimmt auch bald ;(
Ich fände die Möglichkeit des Instancing auch unter OpenGL mehr als angebracht. Neben vielen anderen Faktoren sind tausende von API-Calls nunmal einfach ein bremsender Faktor in einigen Anwendungsbereichen.
Gruss, Carsten.
Demirug
2004-10-30, 13:32:48
Da API-Calls bei OpenGL derzeit weniger CPU lastig sind als bei D3D lohnt sich GI dort weit weniger.
Corrail, "richtige" Superbuffers könnte heute sowieso keine Karte. Ergo müsste eine solche Extension derzeit sehr komplex ausfallen um die ganzen funktioniert und funktioniert nicht Fälle abzudecken.
Das mehr als ein Weg nach Rom führt ist ja nicht unbedingt neu. Das Problem dabei ist dann zumindestens für mich immer eher das man gezwungen ist mit unterschiedlichen Karten unterschiedliche Wege zu nutzen.
Ich finde es zum Beispiel schade das man bei den ganzen neuen Fragmentshader extensions bei OpenGL erst Karten ab DX9 Level berücksichtigt hat. Ähnlich hat es mich geärgert das man bei DX8 keine PS 0.x Version für DX7 Karten eingeführt hat. In diesem Fall hätte man alle Karten programmtechnisch unter einen Hut gebracht und die unterschiede durch konfiguration lösen können.
Corrail
2004-10-30, 14:05:22
Corrail, "richtige" Superbuffers könnte heute sowieso keine Karte. Ergo müsste eine solche Extension derzeit sehr komplex ausfallen um die ganzen funktioniert und funktioniert nicht Fälle abzudecken.
Ja, ich weiß. Aber so wie das ARB derzeit handelt würde es mich EXTREM verwundern, wenn in 2 Jahren OpenGL 3.0 rauskommen... ;)
Und im Großen und Ganzen deckt ja mit VBO, PBO und EXT_framebuffer_object die Superbuffer Funkionalität ab (ich kenn die EXT_framebuffer_object Extension nicht, aber ich nehme mal stark das damit der Großteil der RTT Funkionalität von Superbuffer möglich wird). Ich bin grundsätzlich schon ein Fan von der Superbuffer Extension, aber ich frage mich wofür wir das jetzt noch brauchen?
Das mehr als ein Weg nach Rom führt ist ja nicht unbedingt neu. Das Problem dabei ist dann zumindestens für mich immer eher das man gezwungen ist mit unterschiedlichen Karten unterschiedliche Wege zu nutzen.
Ich finde es zum Beispiel schade das man bei den ganzen neuen Fragmentshader extensions bei OpenGL erst Karten ab DX9 Level berücksichtigt hat. Ähnlich hat es mich geärgert das man bei DX8 keine PS 0.x Version für DX7 Karten eingeführt hat. In diesem Fall hätte man alle Karten programmtechnisch unter einen Hut gebracht und die unterschiede durch konfiguration lösen können.
Ok, das ist ein alt-bekanntes Problem bei OpenGL. Aber es geht derzeit sehr viel in Richtung vendor-unabhängige Extensions. Wenn jetzt noch EXT_framebuffer_object kommt kann man Großteils eh schon einen Weg gehen.
Das DX8 Shader in OpenGL Problem ist leider leider ein alter Hut aber wenn man jetzt mit der Entwicklung einer Engine beginnt (die jetzt mal grob geschätzt mindestens 2 Jahre in der Entwicklung sein wird) würde ich nicht mehr allzuviel Wert auf DX8 Karten legen.
marco42
2004-11-02, 19:09:07
Ich finde es zum Beispiel schade das man bei den ganzen neuen Fragmentshader extensions bei OpenGL erst Karten ab DX9 Level berücksichtigt hat. Ähnlich hat es mich geärgert das man bei DX8 keine PS 0.x Version für DX7 Karten eingeführt hat. In diesem Fall hätte man alle Karten programmtechnisch unter einen Hut gebracht und die unterschiede durch konfiguration lösen können.
da es noch einige zeit dauern wird, bis sich GLSL durchgesetzt haben sollte, ist der support fuer fixed point hardware verschmerzbar. eigentlich unterstuetzen noch nicht mal SM 3.0 karten richtig die shading language. es gibt zB kein noise(das ich wirklich schmerzlich vermisse). und wenn man unbedingt jetzt eine HLSL benutzen will, die auch alte sachen unterstuetzt, wie waere es mit Cg?
Demirug
2004-11-02, 19:24:21
da es noch einige zeit dauern wird, bis sich GLSL durchgesetzt haben sollte, ist der support fuer fixed point hardware verschmerzbar. eigentlich unterstuetzen noch nicht mal SM 3.0 karten richtig die shading language. es gibt zB kein noise(das ich wirklich schmerzlich vermisse). und wenn man unbedingt jetzt eine HLSL benutzen will, die auch alte sachen unterstuetzt, wie waere es mit Cg?
Das Problem mit der nicht garantierten Lauffähigkeit GLSL Programmen habe ich ja schon mal angesprochen. Aber das wird sich ja im Laufe der Zeit von selbst erledigen.
Cg ist leider auch keine Lösung weil es keinen Compiler für R2XX Hardware gibt. Zudem ist der Compiler nicht wirklich so gut.
marco42
2004-11-03, 22:47:46
Das Problem mit der nicht garantierten Lauffähigkeit GLSL Programmen habe ich ja schon mal angesprochen. Aber das wird sich ja im Laufe der Zeit von selbst erledigen.
Cg ist leider auch keine Lösung weil es keinen Compiler für R2XX Hardware gibt. Zudem ist der Compiler nicht wirklich so gut.
ich hoffe mal Cg ist nicht so schlecht, da der GLSL treiber darauf basiert.
Demirug
2004-11-03, 22:54:04
ich hoffe mal Cg ist nicht so schlecht, da der GLSL treiber darauf basiert.
Bezüglich der OpenGL Targets habe ich das nie genauer untersucht aber bei den DX Targets kommt er in der Regel nicht an die Qualität des MS Compilers heran.
Kann es sein, dass das auch die Far Cry Performance beeinträchtigt?
Demirug
2004-11-04, 21:03:31
Kann es sein, dass das auch die Far Cry Performance beeinträchtigt?
Wieso? Spielst du Farcry mit dem OpenGL renderer?
marco42
2004-11-04, 22:53:40
Bezüglich der OpenGL Targets habe ich das nie genauer untersucht aber bei den DX Targets kommt er in der Regel nicht an die Qualität des MS Compilers heran.
Ist die Qualitaet aber nicht auch abhaenig von der Graphic Hardware. Soweit ich weiss, sortieren die Treiber oftmals den Assembler Code wieder um. Oder ist es die simple Geschwindigkeit? Warum sollte eigentlich einen Unterschied zwischen dem DX backend und dem fuer OpenGL bestehen? Besitzt das NV OpenGL backend Befehle, die von SM 2.x oder 3.0 nicht unterstuetzt werden? Ansonsten waere es doch gleich.
Nein, aber verwendet FarCry nicht auch CG für DirectX?
Demirug
2004-11-05, 11:08:53
Ist die Qualitaet aber nicht auch abhaenig von der Graphic Hardware. Soweit ich weiss, sortieren die Treiber oftmals den Assembler Code wieder um. Oder ist es die simple Geschwindigkeit? Warum sollte eigentlich einen Unterschied zwischen dem DX backend und dem fuer OpenGL bestehen? Besitzt das NV OpenGL backend Befehle, die von SM 2.x oder 3.0 nicht unterstuetzt werden? Ansonsten waere es doch gleich.
Der Treiber sortiert schon wieder um. Dabei darf er aber nicht einfach Anweisungen wegwerfen. Er darf nur die Reihenfolge in engen Grenzen verändern. Der Cg Compiler neigt nun dazu beim Übersetzten mehr Anweisungen zu erzeugen als notwendig wären.
Die Backends sind schon unterschiedlich weil jeweils andere Regeln gültig sind und auch teilweise andere Befehle zur verfügung stehen. Selbst die unterschiedlichen Backends für eine API sind ja nicht identisch.
Demirug
2004-11-05, 11:10:02
Nein, aber verwendet FarCry nicht auch CG für DirectX?
Nein, der Cg Compiler wird nur für OpenGL genutzt. Unter DX kommt der MS compiler zum Einsatz bzw viele der Shader liegen schon vorkompiliert (mit dem MS Compiler) in binärer Form vor.
Ah, ok. Der Gast war ich.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.