OpenGL 1.4 [Archiv] - 3DCenter Forum

Ganon

2002-07-16, 15:21:41

SGI hat zusammen mit dem OpenGL Architecture Review Board (ARB) erstmals die Spezifikation 1.4 der plattformunabhängigen Grafik-API vorgestellt. Erweiterungen wurden vor allem in 3D-Bereich vorgenommen. So können in Zukunft realistische Echtzeit-Schatteneffekte mit Hilfe von Depth- und Shadow-Textures erzeugt werden. Ein Vertex Programming Framework schafft die Voraussetzungen für userdefinierte Geometrie-, Licht, und Schattenprogramme und erlaubt die Nutzung allgemeiner High-Level-Shading-Sprachen. Daneben soll in der neuen Version eine automatisierte Texture-Mipmap-Generierung für verbesserte Texturfilterung und Updatefähigkeit der dynamischen Texturen sorgen.
---
Q: THG

aths

2002-07-17, 23:42:22

Na mal sehen, wann es die passenden Treiber dafür gibt.

Demirug

2002-07-25, 12:50:46

Hier ist die Spec:

http://www.opengl.org/developers/documentation/version1_4/glspec14.pdf

und eine Übersicht:

http://www.opengl.org/developers/documentation/OpenGL14.html

aths

2002-07-26, 18:03:07

Cool, noch ganz frisch...

zeckensack

2002-07-26, 20:11:54

Oy! :|

Das werden nicht viele Chips schaffen. Alleine schon wegen der Promotion von EXT_blend_func_seperate (oder so ähnlich) in Core-Funktionalität* fliegt alles unter R200/Geforce3 raus ...

*nicht hauen, Sascha :D

edit:
Korrektur, Geforce 3/4 fliegen auch raus (http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_blend_func_separate). Es bleiben übrig:
R200
Intel 830M :o

nggalai

2002-07-26, 21:16:31

Ola,Originally posted by zeckensack
Core-Funktionalität*

*nicht hauen, Sascha :D
OK.

* TRET *

;)

Danke für die Specs, Demiurg. Muss ich noch durchgehen. Z-Bags Kommentar klingt auf alle Fälle schonmal nach einer interessanten Lektüre. :)

ta,
-Sascha.rb

Demirug

2002-07-26, 21:20:02

Originally posted by nggalai
Ola,OK.

* TRET *

;)

Danke für die Specs, Demiurg. Muss ich noch durchgehen. Z-Bags Kommentar klingt auf alle Fälle schonmal nach einer interessanten Lektüre. :)

ta,
-Sascha.rb

Da ich auf ein paar Spielentwicklerseiten rumsurfe bekomme ich sowas immer recht schnell mit und da ich mitlerweile weiss das es hier daran interesierte Personen gibt poste ich es dann mal schnell.

vogel

2002-07-27, 02:48:39

too little, too late

Was mich am meisten aergert ist, dass es keinen Standard Weg fuer statische Geometrie Daten gibt und NVIDIA's extension ist bei unseren usage patterns quasi nutzlos. ATI's vertex_array_object ist weitaus einfacher zu benutzen als vertex_array_range.

-- Daniel, Epic Games Inc.

zeckensack

2002-07-28, 02:37:25

Originally posted by vogel
too little, too late

Was mich am meisten aergert ist, dass es keinen Standard Weg fuer statische Geometrie Daten gibt und NVIDIA's extension ist bei unseren usage patterns quasi nutzlos. ATI's vertex_array_object ist weitaus einfacher zu benutzen als vertex_array_range.

-- Daniel, Epic Games Inc. Für statische Geometrie braucht man doch keine Extensions ???

Display Lists tun's bei euch nicht?
Theoretisch sollte der Treiber beim Erstellen einer Display List automatisch den besten Transfermodus für statische Geometrie wählen. Von VAR versteh' ich sowieso nichts ...

Unregistered

2002-07-28, 03:13:18

Originally posted by zeckensack
Display Lists tun's bei euch nicht?

Folgendes Szenario (in D3D Jargon) laesst sich nicht mit Display Lists beschleunigen:

Instanced geometry mit seperatem color stream.

vertex stream 1: position, normal, UV
vertex stream 2: diffuse

Alle Instanzen teilen vertex stream 1 aber haben eigenen vertex stream 2.

Bleiben nur vertex arrays + NV_vertex_array_range/ ATI_vertex_array_object uebrig. ATI's extension ist fast 100% identisch mit dem was D3D zu bieten hat und NVIDIA's ist fuer uns nicht zu gebrauchen.

-- Daniel, Epic Games Inc.

vogel

2002-07-28, 03:16:38

zeckensack

2002-07-28, 03:37:44

Originally posted by vogel
Folgendes Szenario (in D3D Jargon) laesst sich nicht mit Display Lists beschleunigen:

Instanced geometry mit seperatem color stream.

vertex stream 1: position, normal, UV
vertex stream 2: diffuse
Alle Instanzen teilen vertex stream 1 aber haben eigenen vertex stream 2.
Aah soo :)
Das ist natürlich nichts für Display Lists.
Nitpick: Ist ja auch nicht komplett statisch :P
;)Bleiben nur vertex arrays + NV_vertex_array_range/ ATI_vertex_array_object uebrig. ATI's extension ist fast 100% identisch mit dem was D3D zu bieten hat und NVIDIA's ist fuer uns nicht zu gebrauchen.

-- Daniel, Epic Games Inc. Also wie gesagt, von VAR verstehe ich momentan (noch) garnichts, ich habe zwar einen Rechner im Nebenraum, auf dem ich das mal ausprobieren könnte, aber bisher habe ich nicht mal die Spec gelesen ...

Daher Gegenfrage: Das Problem läßt sich doch mit der Vertex Array-Semantik lösen (wenn auch nicht sonderlich schnell).
Also, glColorPointer, glNormalPointer, glTexCoordPointer, glVertexPointer.

Die einzelnen Zeiger kann man AFAIK doch hinsetzen, wo man will. Kann man dann nicht den statischen Teil mit VAR ins Graka-RAM setzen und die Farbwerte aus dem Sys-RAM hinterherstreamen? Oder muß man bei VAR komplett neue Entry points benutzen?

*amkopfkratz*
*speclesengeh*

vogel

2002-07-28, 04:48:24

Originally posted by zeckensack
Nitpick: Ist ja auch nicht komplett statisch :P

Die Geometrie Daten aendern sich nie :)

Daher Gegenfrage: Das Problem läßt sich doch mit der Vertex Array-Semantik lösen (wenn auch nicht sonderlich schnell).
Also, glColorPointer, glNormalPointer, glTexCoordPointer, glVertexPointer.

Ja, da Standard vertex arrays im Client- Addressraum == system memory sind muss die CPU diese jedes mal zur GPU schaufeln :(

Die einzelnen Zeiger kann man AFAIK doch hinsetzen, wo man will. Kann man dann nicht den statischen Teil mit VAR ins Graka-RAM setzen und die Farbwerte aus dem Sys-RAM hinterherstreamen? Oder muß man bei VAR komplett neue Entry points benutzen?

Das Problem bei VAR ist das man seine eigene Speicherverwaltung schreiben muss, die Implementierung tuecken hat, und und und. Im Grunde (ohne erheblichen Aufwand) nur fuer "kleine" dynamische Buffer geignet. Jedenfalls hab ich es noch nicht geschafft 16 MByte vertex Daten mit VAR zu verwalten. Wenn NVIDIA doch blos ATI's extension unterstuetzen wuerde...

-- Daniel, Epic Games Inc.

vogel

2002-07-28, 04:53:08

Originally posted by zeckensack
man dann nicht den statischen Teil mit VAR ins Graka-RAM setzen und die Farbwerte aus dem Sys-RAM hinterherstreamen? Oder muß man bei VAR komplett neue Entry points benutzen?

Die Farbwerte sind auch statisch -> mit D3D liegt alles im video memory.

Unabhaengig davon: ich glaube nicht das VAR es zulaesst zwei verschiedene Speicherregionen zu benuzten. GF2/ GF4MX koennen das naemlich nicht. Deshalb "precachen" wir als erstes vertex buffers und dann erst Texturen da es fuer Performance fatal ist einen (FFP) vertex shader zu benuzten der streams aus verschiedenen Speicherarten referenziert.

-- Daniel, Epic Games Inc.

vogel

2002-07-28, 08:33:20

Originally posted by zeckensack
Das werden nicht viele Chips schaffen. Alleine schon wegen der Promotion von EXT_blend_func_seperate (oder so ähnlich) in Core-Funktionalität* fliegt alles unter R200/Geforce3 raus ...

*nicht hauen, Sascha :D

edit:
Korrektur, Geforce 3/4 fliegen auch raus (http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_blend_func_separate). Es bleiben übrig:
R200
Intel 830M :o
Nur weil NVIDIA EXT_blend_func_separate im Augenblick nicht unterstuetzt heisst das noch lange nicht, dass das die HW nicht kann. Z.b. unterstuetzt NVIDIA im Augenblick auch nicht ARB_texture_env_crossbar jedoch kann die HW das. Interessanterweise kann ich mich dran erinnern, dass die Linux OpenGL Treiber EXT_texture_env_crossbar vor 2 Jahren unterstuetzt haben - auf jeden Fall hab ich es damals fuer UT's OpenGL renderer zeitweise mal benutzt... oder vielleicht warens damals die Voodoo 5 Treiber. Hmmm.

-- Daniel, Epic Games Inc.

zeckensack

2002-07-28, 09:24:10

Originally posted by vogel

Nur weil NVIDIA EXT_blend_func_separate im Augenblick nicht unterstuetzt heisst das noch lange nicht, dass das die HW nicht kann.Wäre möglich :)
Leider werden oft auch rein aus politischen Gründen einige EXTs nicht unterstütz.
Z.b. unterstuetzt NVIDIA im Augenblick auch nicht ARB_texture_env_crossbar jedoch kann die HW das. Interessanterweise kann ich mich dran erinnern, dass die Linux OpenGL Treiber EXT_texture_env_crossbar vor 2 Jahren unterstuetzt haben - auf jeden Fall hab ich es damals fuer UT's OpenGL renderer zeitweise mal benutzt... oder vielleicht warens damals die Voodoo 5 Treiber. Hmmm.

-- Daniel, Epic Games Inc.
Auf jeden Fall können die Karten das! Ich habe das mal irgendwo in den ARB Meeting Notes gefunden, warum das jetzt nicht mehr mitgemacht wird. Und zwar:
Entgegen allgemein üblicher OpenGL-Gepflogenheiten spezifiziert ARB_texture_env_crossbar, daß eine nicht korrekt konfigurierte Textureinheit (keine Textur gebunden) ein schwarzes Ergebnis produzieren soll (0;0;0;1). NV_register_combiners (und ein paar andere Sachen, inklusive der alten EXT_ version) spezifizieren dagegen weiß (1;1;1;1).

NVIDIA hatte dann das Problem, daß der Treiber nicht wissen kann, ob das Programm jetzt die ARB- oder die EXT-Version haben will, deswegen hat man das ganze einfach gekickt. Die haben auch kräftig gegen diese Änderung gewettert (IMO zu Recht), haben aber nichts erreicht :|

Btw: Eine Voodoo 1 hätte auch die nötige Hardware für EXT_blend_func_seperate. Da kenne ich mich aus :D

vogel

2002-07-28, 09:27:45

Originally posted by vogel
Nur weil NVIDIA EXT_blend_func_separate im Augenblick nicht unterstuetzt heisst das noch lange nicht, dass das die HW nicht kann.
Damit wollte ich nicht implizieren, dass NVIDIA HW das kann - keine Ahnung. Spielt aber auch keine Rolle da 'ne GeForce 2 z.B. keine 3D Texturen unterstuetzt aber sehr wohl OpenGL 1.2 Treiber hat... wenn man sie benutzt heissts dann halt software rasterization :)

-- Daniel, Epic Games Inc.

zeckensack

2002-07-28, 15:49:16

Ah, daran erinnere ich mich dunkel (http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/009102.html) ... ;)

aths

2002-07-28, 20:04:09

zeckensack,

welche HW-Fähigkeiten fehlen NV20/25 denn, um EXT_blend_func_seperate supporten zu können?

Und eine zweite, verschwörungstheoretische Frage :) Bist du persönlich der Meinung, dass nV mit einem stärkeren Gewicht im ARB diese Extenstion verhindert hätte, um OpenGL 1.4 nicht GF3/4 zu verschließen?

RadioactiveMan

2002-07-28, 23:45:35

@ aths

Der GF3/4 fehlt anscheinend die Möglichkeit den Blend Faktor für die Farb(RGB)- bzw. Alpha(A) Werte seperat einzustellen.

Hier noch ein Posting von einem der NVIDIA OpenGL Treiberentwickler(mcraighead) dazu: http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/004312.html

Und um deine zweite Frage zu beantworten(wobei ich eh denke das du mich aus 3dcenter verschwörungstheoretischen Gründen ignorierst), NVIDIA hat in der ARB nicht unbedingt viel zu sagen und wird nicht unbedingt jede kleine Fizelextension boykotieren(die nur für sehr wenige Entwickler relevant sind) nur weil ihre HW sie nicht unterstützt. Vielmehr konzentrieren sie sich sicherlich darauf ihre wichtigeren Extensions (z.b. NV(oder halt die neue ARB)_vertex_program) in die Opengl Spezifikationen einzubringen, wo sie selbst die Implementierungsdetails regeln können.

zeckensack

2002-07-29, 05:28:50

Na dann ... wenn Matt sagt, daß die Hardware das nicht kann, dann dürfte doch klar sein, warum die Extension fehlt :)

Zur Verschwörungstheorie: Sowas passiert schonmal. Das hat nichts mit Boykott zu tun. ATI und NV reißen sich förmlich darum, das Maximum an EXT- und ARB-Extensions einzubauen, schließlich sind beide mittlerweile auch im Profi-Segment tätig. Das läuft aber nicht so, daß die extra Chips bauen, die alles (http://oss.sgi.com/projects/ogl-sample/registry/) können, man muß ja auch auf den Transistorcount achten.

Davon würde ich eher dann sprechen, wenn NVIDIA keine ATI-Extensions einbaut, oder umgekehrt. Das liegt dann oft daran, daß die Hardwaredetails sich stark unterscheiden (zB bei den Pixel Shadern) und das garnicht möglich wäre.

Zb ist es unmöglich, ATI_fragment_shader auf NVIDIA-Hardware anzubieten.
IMO ist es genauso unmöglich, die NV-Extensions dazu (NV_register_combiners/2, NV_texture_shader/2/3) allgemeingültig auf ATI-Hardware abzubilden.

NVIDIA wird sich IMO nicht lumpen lassen und den nächsten Chip mit der entsprechenden Fähigkeit ausrüsten. Daß EXT_blend_func_seperate reinkommt, ist denen wahrscheinlich früh genug klar gewesen, aber für Geforce3 und 4 war OpenGL1.4 einfach noch kein Thema.

zeckensack

2002-07-29, 05:59:38

Übrigens fliegt der R200 auch wieder raus, weil EXT_depth_textures nicht unterstützt werden (Gf3/4 können das).

Damit kann kein aktuell erhältlicher Chip volle GL1.4-Funktionalität (*vorsaschadavonrenn*) bieten.

Damit herrscht wieder Gleichstand, auch was die Verschwörungstheorien angeht :)

vogel

2002-07-29, 07:15:18

Originally posted by zeckensack
Damit kann kein aktuell erhältlicher Chip volle GL1.4-Funktionalität (*vorsaschadavonrenn*) bieten.

Sehr wahrscheinlich P10 und R300 je nachdem wie du erhaeltlich definierst ;-)

-- Daniel, Epic Games Inc.

zeckensack

2002-07-29, 07:43:17

Originally posted by vogel

Sehr wahrscheinlich P10 und R300 je nachdem wie du erhaeltlich definierst ;-)

-- Daniel, Epic Games Inc. Aktuell erhältlich = kann ich mir jetzt sofort kaufen.

Also maximal Geforce4Ti oder Radeon8500.
Btw, wäre sehr interessant zu wissen, ob der Radeon9000 vielleicht noch mehr Features spendiert wurden, mal abgesehen von BullStream ;)

edit: Shadow Buffers aka Depth Textures wären sehr sinnvoll gewesen, um mit Geforce3/4 gleichzuziehen ?-)

edit2: Ich Eselchen. Wildcat VP kann man doch schon kaufen, oder? Hrrrr :|

aths

2002-07-29, 09:40:10

Das heisst, für GeForce3 und 4 wird es keine Treiber geben, die "OpenGL 1.4" vermelden?!

Arrr...

Demirug

2002-07-29, 09:55:33

Originally posted by aths
Das heisst, für GeForce3 und 4 wird es keine Treiber geben, die "OpenGL 1.4" vermelden?!

Arrr...

Nein das heisst es nicht. Wenn es Treiber gibt (wovon ich ausgehe) und ein Programm möchte etwas benutzen was die Karte nicht kann -> Softwarerendering. Sowas ist bei OpenGL erlaubt.

aths

2002-07-29, 10:25:19

Wie ist das mit dem Software-Rendering zu verstehen? Ich kann mir jetzt schwer vorstellen, nur diese Blend-Funktion in SW machen zu lassen und den Rest in HW. Nicht dass das unmöglich wäre, aber die Performance wohl absolut unbrauchbar, wenn alle entsprechenden Fragmente über die CPU müssten...

Ist, wenn SW Rendering erlaubt ist, dann sogar damit zu rechnen dass es OpenGL-Treiber geben wird die Version 2.0 vermelden?

Demirug

2002-07-29, 10:46:00

zeckensack

2002-07-29, 11:57:19

Originally posted by aths
Wie ist das mit dem Software-Rendering zu verstehen? Ich kann mir jetzt schwer vorstellen, nur diese Blend-Funktion in SW machen zu lassen und den Rest in HW. Nicht dass das unmöglich wäre, aber die Performance wohl absolut unbrauchbar, wenn alle entsprechenden Fragmente über die CPU müssten...Genau das passiert, wenn man auf einer Geforce2 3D-Texturen nutzt.
Der Treiber meldet OpenGL1.3-Konformität, muß die Funktion also anbieten. Da die Hardware das aber nicht kann, geht das ganze dann in pures SW-Rendering über, mit den entsprechenden Frameraten.

Übrigens meldet der Treiber EXT_texture_3d nicht als unterstützte Extension, was ja auch mehr oder weniger der Wahrheit entspricht (kein Hardware-Support).

Es ist eigentlich üblich, die GL-Version überhaupt nicht abzufragen, sondern nur die unterstützten Extensions (alle 'alten' Extensions, die in neuere Versionen der Core-Spec aufgenommen wurden, sollen wg Kompatibilität zu alten Applikationen sowieso weiterhin gemeldet werden). Daß die Extension unterstützt wird, bedeutet dann nicht zwangsläufig daß sie in Hardware unterstützt wird, aber es bedeutet daß sie vernünftig ("fast enough") nutzbar ist.

Von daher ist es letztendlich garnicht soo wichtig, wie die neue Spec an sich ausschaut, viel wichtiger sind die neuen ARB-Versionen alter herstellerspezifischer Extensions, die dafür ausgearbeitet wurden. Ein netter Text, der im Zusammenhang erklärt, wie das alles zu funktionieren hat ist natürlich auch eine nette Sache :)