Erste OpenGL 2.0 Core Extensions online

[Corrail]

Die ersten OpenGL 2.0 Core Extension sind seit kurzem online. Zwar nicht wirklich was neues, aber dafür in ARB gehalten ;)

ARB_draw_buffers (http://oss.sgi.com/projects/ogl-sample/registry/ARB/draw_buffers.txt)
ARB_texture_rectangle (http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_rectangle.txt)

Bei ARB_texture_rectangle wird nun auch die Interaktion mit GLSL beschrieben.

Ich warte schon (un)geduldig auf die weiteren Extensions... ;)

[Chris Lux]

Die ersten OpenGL 2.0 Core Extension sind seit kurzem online. Zwar nicht wirklich was neues, aber dafür in ARB gehalten ;)

ARB_draw_buffers (http://oss.sgi.com/projects/ogl-sample/registry/ARB/draw_buffers.txt)
ARB_texture_rectangle (http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_rectangle.txt)

Bei ARB_texture_rectangle wird nun auch die Interaktion mit GLSL beschrieben.


woah cool, da kann man jetzt wieder auf treiber warten, die es unterstützen. hoffentlich dauert es nicht all zu lang.

Ich warte schon (un)geduldig auf die weiteren Extensions... ;)

auf welche wartest du? ;) ich hätte da auch ein zwei wünsche

edit: was ich mir nicht wünsche, sondern was ich WILL ist pure openGL2.0, was aber scheinbar nicht kommen wird. schade, denn eine saubere, vereinfachte API würde viele probleme verschwinden lassen.

[Asmodeus]

woah cool, da kann man jetzt wieder auf treiber warten, die es unterstützen. hoffentlich dauert es nicht all zu lang.

Da sich volle OpenGL 2.0 Unterstützung bestimmt auch gut als Werbefeature vermarkten lässt, wird es mit den passenden Treibern gewiss nicht sooo lange dauern. ;) Nach der offiziellen Vorstellung auf der Siggraph geht es sicher relativ flott.

Gruss, Carsten.

[Chris Lux]

Da sich volle OpenGL 2.0 Unterstützung bestimmt auch gut als Werbefeature vermarkten lässt, wird es mit den passenden Treibern gewiss nicht sooo lange dauern. ;) Nach der offiziellen Vorstellung auf der Siggraph geht es sicher relativ flott.


das hoffe ich sehr, doch ist opengl seit langem kein werbewirksames argument mehr, leider. schade finde ich, dass man pure opengl2.0 aufgeschoben oder gar ganz aufgehoben hat. dieser schritt hätte viel bewegung in viele echtzeit sw und libraries gebracht. schade drum ;)

opengl2.0 stellt so für mich nicht wirklich einen grossen schritt dar, nur wieder eine hand voll extensions, mehr nicht.

edit:
http://www.opengl.org/about/arb/notes/GL_memory_access.pdf

dieses unkonventionelle pdf sagt viel aus, wie man sich ein pur opengl2.0 wünschen würde.

[Xmas]

edit:
http://www.opengl.org/about/arb/notes/GL_memory_access.pdf

dieses unkonventionelle pdf sagt viel aus, wie man sich ein pur opengl2.0 wünschen würde.
:o
Ganz interessant, aber das erste was mir dazu einfällt ist "Finger weg von Drogen"...

[Chris Lux]

Ganz interessant, aber das erste was mir dazu einfällt ist "Finger weg von Drogen"...

hehe, ist aus den letzten arb meeting notes von der superbuffers working group. mir tut es weh solche guten ideen zu sehen, welche es aber nie schaffen... aus welchen mir rätselhaften gründen auch immer.

[Corrail]

Naja, das mit den Superbuffers ist so eine Sache...
Schaut mal hier, Seite 32
http://download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_OpenGL_exts.pdf


Uber/super buffers extension coming soon


Mich hats echt umgehaut, dass sowas in einer nVidia-Präsentation vorkommt, also scheinen die Superbuffer doch noch nicht ganz ausgestorben zu sein ;)


auf welche wartest du? ;) ich hätte da auch ein zwei wünsche


Naja, an erster Stelle warte ich mal, welche Extension jetzt für die Speicherverwaltung kommt: PBO oder Superbuffer? Oder beide?
An zweiter Stelle hätte ich unbedingt gerne eine Extension, wo ich Render Targets verwalten kann, ala EXT_render_target. Ich mag keine PBuffer... ;) Das wäre ja in Superbuffers eh schon drinnen, na gut, bin schon mal gespannt.
Dann sollten noch folgende Extensions kommen: floating point buffer/textures, two side stencil, color clamp control

[Asmodeus]

An zweiter Stelle hätte ich unbedingt gerne eine Extension, wo ich Render Targets verwalten kann, ala EXT_render_target. Ich mag keine PBuffer... ;) Das wäre ja in Superbuffers eh schon drinnen, na gut, bin schon mal gespannt.

Oh ja, endlich Schluss mit diesem PBuffer Mist und dem dazugehörigen Windows Kram. Ich möchte endlich wieder Offscreen Buffer haben, die nicht wie jetzt mein PBuffer langsamer als mein Backbuffer sind ;)

Gruss, Carsten.

[Chris Lux]

Dann sollten noch folgende Extensions kommen: floating point buffer/textures, two side stencil, color clamp control

full ack, aber wenn fp textures, dann auch die möglichkeit bieten für fp16 und das dann aber auch in den shadern. was für mich bedeutet die shader spec um fp16 (oder wie die es auch nennen wollen) zu erweitern. was nicht unbedingt sein muss sind fixed point typen, wäre aber trotzdem fein.

[Corrail]

full ack, aber wenn fp textures, dann auch die möglichkeit bieten für fp16 und das dann aber auch in den shadern. was für mich bedeutet die shader spec um fp16 (oder wie die es auch nennen wollen) zu erweitern. was nicht unbedingt sein muss sind fixed point typen, wäre aber trotzdem fein.

Laut den letzten (oder soll ich besser sagen: vorletzten ;)) ARB-Notes wird die floating point texture Extension auf Basis von ATI_texture_float gebastelt. http://oss.sgi.com/projects/ogl-sample/registry/ATI/texture_float.txt
Da sind sowohl FP32 als auf FP16 textur formate definiert.

[sth]

Das klingt doch schonmal gut.
Jetzt frage ich mich nur, ob nVidia's FXer die ARB-Extension unterstützen werden (bzw hardwaremäßig überhaupt könnten), denn die ATI-Extension wird zur Zeit nur von r3xx/r4xx und NV4x unterstützt.

[Corrail]

Das klingt doch schonmal gut.
Jetzt frage ich mich nur, ob nVidia's FXer die ARB-Extension unterstützen werden (bzw hardwaremäßig überhaupt könnten), denn die ATI-Extension wird zur Zeit nur von r3xx/r4xx und NV4x unterstützt.

Das ist eine gute Frage, aber ich glaube nicht. GeForce FX unterstützt zwar auch floating point buffer, allerdings nur für GL_TEXTURE_RECTANGLE_NV/EXT/ARB Texture targets. Bezweifle daher, dass es die ARB_texture_float (ich nenne die Extension jetzt mal so) auch für die GeForce FX Serie geben wird.

[Chris Lux]

Laut den letzten (oder soll ich besser sagen: vorletzten ;)) ARB-Notes wird die floating point texture Extension auf Basis von ATI_texture_float gebastelt.
Da sind sowohl FP32 als auf FP16 textur formate definiert.

jap ich weiss, hoffe halt nur, dass dies auch übernommen wird und sich nicht wieder nur auf float beschränkt wird.

Das ist eine gute Frage, aber ich glaube nicht. GeForce FX unterstützt zwar auch floating point buffer, allerdings nur für GL_TEXTURE_RECTANGLE_NV/EXT/ARB Texture targets. Bezweifle daher, dass es die ARB_texture_float (ich nenne die Extension jetzt mal so) auch für die GeForce FX Serie geben wird.

jup, dies werden dann nur die karten bringen, die auch die ati extension zZ unterstützen. speziell hierbei interessiert mich dann wie man die beschränkungen was die ganz spezielle fähigkeiten angeht ersichtlich macht. sprich, dass nur fp16 blending und filtern unterstützt wird und nicht wie die extension vermuten lässt auch für volle ieee fp.

[sth]

GeForce FX unterstützt zwar auch floating point buffer, allerdings nur für GL_TEXTURE_RECTANGLE_NV/EXT/ARB Texture targets.
...was ich sehr verwunderlich finde, denn das würde ja im Endeffekt nur heissen, dass die FX bei Floating-Point Buffern nicht mit relativen Texturkoordinaten arbeiten könnte, oder? Diese Limitation würde mich gerade bei nVidia doch sehr verwundern...

[Chris Lux]

...was ich sehr verwunderlich finde, denn das würde ja im Endeffekt nur heissen, dass die FX bei Floating-Point Buffern nicht mit relativen Texturkoordinaten arbeiten könnte, oder? Diese Limitation würde mich gerade bei nVidia doch sehr verwundern...

genau das heisst es ;) und genau so ist es auch. in erster linie sind die float buffer auch als (fullscreen) render targets gedacht, welche dann für multipass algorithmen wieder als eingabe für den shader dienen können. somit finde ich es auch gut, dass sie mit den nicht normalisierten coordinaten addressiert werden.

[sth]

Ich benutze TEXTURE_RECTANGLE momentan für einen netten Glow-Filter (siehe hier (http://moon3d.sourceforge.net/pp-fx/q3dm17-glow.png)), den könnte ich demnach auch auf der FX mit Float-Textures machen.

Nur bringt mir das zur Zeit leider noch nichts, da die für den Effekt (nicht shader-basierend) benötigten Zwischentexturen immernoch durch die Präzision des Framebuffers limitiert sind.

Ich bin daher immernoch auf der Suche nach einer platformunabhänigen Methode um dies zu umgehen, d.h. man müsste theoretisch die ganzen Zwischenschritte direkt in eine FP-Textur rendern, aber wie? Selbst auf Hardware ohne FP-Textur-Support könnte man dann zumindest eine RGB16-Textur verwenden, was schon eine erhebliche Steigerung gegenüber dem RGBA8-Framebuffer sein dürfte...

Hat jemand 'ne Idee?

(sorry wegen OT)

[zeckensack]

An zweiter Stelle hätte ich unbedingt gerne eine Extension, wo ich Render Targets verwalten kann, ala EXT_render_target.Steht bei mir ganz oben auf der Wunschliste. IMO wäre das auch ein guter Grund gewesen, GL2 noch ein wenig weiter zu verzögern. Das hätte auf jeden Fall da hinein gehört. Wenn die WG noch nicht damit fertig geworden ist, dann hätte man eben warten müssen. R2T ist ja nun nicht weniger wichtig als NPoTT, im Gegenteil. Das DXG-Camp erfreut sich schon seit Ewigkeiten an robuster R2T-Funktionalität, und Pbuffers sind IMO der grösste Krampf den OpenGL-Entwickler sich momentan antun müssen. Dabei gibt's so viele Leute die R2T gut gebrauchen können ...

Naja, wahrscheinlich wollte man einfach zur Siggraph eine neue Spec raushauen. Positiv finde ich das nicht.

[Corrail]

Jetzt ist es auch auf opengl.org online:


OpenGL 2.0 announced - specification expected by August 31st

August 11, 2004 The OpenGL Architecture Review Board announced the OpenGL 2.0 specification. New features of OpenGL 2.0 include:
Programmable shading - With the new release, both OpenGL Shading Language and its APIs are now core features of OpenGL. New functionality includes the ability to create shader and program objects; and the ability to write vertex and fragment shaders in OpenGL Shading Language.
Multiple render targets that enable programmable shaders to write different values to multiple output buffers in a single pass.
Non-power-of-two textures for all texture targets, thereby supporting rectangular textures and reducing memory consumption.
Two-sided stencil with the ability to define stencil functionality for the front and back faces of primitives, improving performance of shadow volume and constructive solid geometry rendering algorithms.
Point sprites which replace point texture coordinates with texture coordinates interpolated across the point. This allows drawing points as customized textures, useful for particle systems.


Und nochmal 3 Wochen warten... :(

[Chris Lux]

Und nochmal 3 Wochen warten... :(

auf was? das gibts doch alles schon, bloss ned als offiziellen core bestandteil. also ich bin sehr enttäuscht, aber eigentlich hab ich ja gar nix anderes erwartet. :(

[Corrail]

Stimmt, Blödsinn...
Selbst two sided stencil extension gibt es schon (ich nehme an EXT_stencil_two_side wird genommen). Naja, hoff ma, dass es bald weitere Extension gibt. Ich warte eigentlich noch immer auf die wichtigsten.

[zeckensack]

...was ich sehr verwunderlich finde, denn das würde ja im Endeffekt nur heissen, dass die FX bei Floating-Point Buffern nicht mit relativen Texturkoordinaten arbeiten könnte, oder? Diese Limitation würde mich gerade bei nVidia doch sehr verwundern...Jein. {NV|EXT|ARB}_texture_rectangle bedeutet primär keine Mipmaps.

[Chris Lux]

...was ich sehr verwunderlich finde, denn das würde ja im Endeffekt nur heissen, dass die FX bei Floating-Point Buffern nicht mit relativen Texturkoordinaten arbeiten könnte, oder? Diese Limitation würde mich gerade bei nVidia doch sehr verwundern...
Jein. {NV|EXT|ARB}_texture_rectangle bedeutet primär keine Mipmaps.

ich würde da nicht nur diese eine einschränkung in den fordergrund stellen:
aus der spec:

NPOTD textures are accessed by non-normalized texture coordinates.
So instead of thinking of the texture image lying in a [0..1]x[0..1]
range, the NPOTD texture image lies in a [0..w]x[0..h] range.

das ist das worauf sth wohl rauswollte, und was für die primären anwendungsgebiete der RECTs imo auch sinn macht.

[Corrail]

Hier ein Überblick über OpenGL 2.0 und die nächsten Pläne für OpenGL:

http://www.opengl.org/about/news/siggraph2004/bof2004_intro_web.pdf

ich würde da nicht nur diese eine einschränkung in den fordergrund stellen:
aus der spec:

NPOTD textures are accessed by non-normalized texture coordinates.
So instead of thinking of the texture image lying in a [0..1]x[0..1]
range, the NPOTD texture image lies in a [0..w]x[0..h] range.

das ist das worauf sth wohl rauswollte, und was für die primären anwendungsgebiete der RECTs imo auch sinn macht.

Ich glaub nicht, dass es an den Textur-Koordinaten liegt. Die kann man mit dem Treiber sicher nachbearbeiten. Die wirklich Beschränkung liegt genau da, was Zeckensack gemeint hat, am Mip-Mapping.

BTW, Rendermonkey 1.5 ist herrausen: http://developer.3dlabs.com/openGL2/rendermonkey/download.htm

[Chris Lux]

Ich glaub nicht, dass es an den Textur-Koordinaten liegt. Die kann man mit dem Treiber sicher nachbearbeiten. Die wirklich Beschränkung liegt genau da, was Zeckensack gemeint hat, am Mip-Mapping.

das ist mir auch klar, meine antwort bezog ich aber auf sths posting. wenn das format generell kein filtern erlaubt ist das mit dem mipmapping auch an sich klar, oder? die RECTs sollen ja keine generellen NPOTTs sein, dafür gibt es ja nun schon eine eigene extension, sie sind eben für fullscreen effekte gedacht und da macht das mit den noch normalisierten koordinaten sinn, da man sonst entweder im shader den textel offset berechnen muss oder ihn als uniform eingeben muss, in beiden fällen müssen aber informationen über die dimension eingegeben werden. was der treiber daraus nun macht ist wurscht und im umgang mit diesen texturtypen ist eben der adressierungsmodus IMO wichtiger zu wissen, da man sich sonst nur auf dem allerersten texel bewegt ;).

edit: wenn ich richtig verstehe, was du meinst mit dem mipmapping und dem adressieren, das könnte man auch im treiber lösen, denn der weiss ja auch welche dimension und welchen mipmaplevel er gerade bearbeitet. ich würde die beschränkung wirklich nicht nur an dieser einen festmachen. nochmal, die RECTs sind für eine anwendung speziell geschaffen und für diese machen die einschränkungen imo sinn.

[zeckensack]

das ist mir auch klar, meine antwort bezog ich aber auf sths posting. wenn das format generell kein filtern erlaubt ist das mit dem mipmapping auch an sich klar, oder?1)Macht ATI_texture_float (http://oss.sgi.com/projects/ogl-sample/registry/ATI/texture_float.txt) keinerlei Einschränkungen in Bezug auf Filter. Ergo: wenn die Extension unterstützt wird, müssen gefilterte Float-Texturen funktionieren.
2)Mal abgesehen von Punkt 1 gäbe es theoretisch noch den Grenzfall GL_NEAREST_MIPMAP_NEAREST, was ja nun nicht direkt ein "Filter" im eigentlichen Sinn ist, aber eben trotzdem Mipmaps braucht.
die RECTs sollen ja keine generellen NPOTTs sein, dafür gibt es ja nun schon eine eigene extension, sie sind eben für fullscreen effekte gedacht und da macht das mit den noch normalisierten koordinaten sinn, da man sonst entweder im shader den textel offset berechnen muss oder ihn als uniform eingeben muss, in beiden fällen müssen aber informationen über die dimension eingegeben werden.Mir scheint, du hast die Interpolation von Texturkoordinaten noch nicht ganz verstanden. Du musst keine Offsets eingeben, das ist sogar falsch. Du kriegst ein 1:1-Mapping einer konventionellen Textur auf ein Quad gleicher (Pixel-)Grösse, indem du einfach die Texturkoordinaten (0;0), (1;0), (1;1), (0;1) benutzt. Alles andere führt zu Problemen wenn du filterst.

Bei Rechteckstexturen: dito, nur anders. Für eine 640x480-Textur in ein 640x480-Fenster nimmst du einfach die Texturkoordinaten (0;0), (640;0), (640;480), (0;480) und gut ist's.

[Chris Lux]

1)Macht ATI_texture_float (http://oss.sgi.com/projects/ogl-sample/registry/ATI/texture_float.txt) keinerlei Einschränkungen in Bezug auf Filter. Ergo: wenn die Extension unterstützt wird, müssen gefilterte Float-Texturen funktionieren.

aber nicht, wenn man ein RECT target nimmt, um was es in dieser diskussion eigentlich geht (siehe auch dein erstes posting) und auf dieses habe ich geantwortet.
Mir scheint, du hast die Interpolation von Texturkoordinaten noch nicht ganz verstanden.

entschuldigung?!? ;)

Du musst keine Offsets eingeben, das ist sogar falsch. Du kriegst ein 1:1-Mapping einer konventionellen Textur auf ein Quad gleicher (Pixel-)Grösse, indem du einfach die Texturkoordinaten (0;0), (1;0), (1;1), (0;1) benutzt. Alles andere führt zu Problemen wenn du filterst.

Bei Rechteckstexturen: dito, nur anders. Für eine 640x480-Textur in ein 640x480-Fenster nimmst du einfach die Texturkoordinaten (0;0), (640;0), (640;480), (0;480) und gut ist's.

ich arbeite schon sehr lange mit ogl und auch schon mit den rects und ich kenne mich (ich mag es nicht mich selbst so darzustellen) sehr gut mit diesen verfahren aus!... ich bezog mich bei den offsets auf filterkernimplementationen, welche man sehr oft mit rects implementiert. bei einem rect benutzt du einfach +-1 um die umliegenden texel zu bekommen. nutzt du eine normale textur musst du einen von der auflösung der textur abhängigen offset berechnen. so und nicht anders habe ich das gemeint.

wenn du dich bei deinem ersten post auf NV_float_buffer bezogen hast stimmt das mit dem mipmapping, jedoch hast du von den RECTs gesprochen und bei denen gibt es neben dieser beschränkung halt noch andere einschränkungen, worauf ich hinaus wollte in bezog auf sths posting.

[zeckensack]

aber nicht, wenn man ein RECT target nimmt, um was es in dieser diskussion eigentlich geht (siehe auch dein erstes posting) und auf dieses habe ich geantwortet.Ja, aber es tauchte auch die Frage auf, warum die FXen ATI_texture_float nicht unterstützen, und ob das irgendwann noch kommt. Und ich dachte es dreht sich gerade darum.
entschuldigung?!? ;)

ich arbeite schon sehr lange mit ogl und auch schon mit den rects und ich kenne mich (ich mag es nicht mich selbst so darzustellen) sehr gut mit diesen verfahren aus!... ich bezog mich bei den offsets auf filterkernimplementationen <...>Da habe ich wohl zu schnell geschossen. Ja, das ist natürlich größenabhangig. Sry, mein Fehler ;(

wenn du dich bei deinem ersten post auf NV_float_buffer bezogen hast stimmt das mit dem mipmapping, jedoch hast du von den RECTs gesprochen und bei denen gibt es neben dieser beschränkung halt noch andere einschränkungen, worauf ich hinaus wollte in bezog auf sths posting.Ich habe hier nur versucht herauszuarbeiten, warum die FXen NV_float_buffer und NV_texture_rectangle unterstützen, aber nicht ATI_texture_float. NV_texture_rectangle sieht sowieso keine Mipmaps vor, ATI_texture_float dagegen definiert eine Erweiterung zum "normalen" Texturmechanismus, und da wären Mipmaps und sämtliche Filtermodi dann eben auch "orthogonal" zu unterstützen. Da die FXen von der Hardware her Float-Texturen weder filtern noch mipmappen können, wäre der Support von ATI_texture_float theoretisch zwar möglich, aber grösstenteils nur über Software-Fallbacks, und die will ja im Grunde sowieso keiner haben. HW-beschleunigt wäre es nur dann, wenn man genau die Untermenge trifft, die durch NV_float_buffer gebildet wird ...
There are several significant limitations on the use of floating-point
color buffers. First, floating-point color buffers do not support frame
buffer blending. Second, floating-point texture maps do not support
mipmapping or any texture filtering other than NEAREST. Third,
floating-point texture maps must be 2D, and must use the
NV_texture_rectangle extension.Dann kann man auch gleich auf ATI_texture_float verzichten, und nur das offenlegen was die Hardware sowieso kann.

Das mit den unterschiedlichen Koordinaten sehe ich immer noch etwas unkritisch. Das ist über ein simples MUL im Vertex Shader korrigierbar, die Konstante zur Kompensation kann man einfach immer neu laden, wenn eine Textur anderer Größe gebunden wird. Ist IMO alles nicht so kompliziert, und Ich traue den Treiber-Jungens zu, das ohne große Probleme "emulieren" zu können.

Alles nur der Vollständigkeit halber ;)
*schweißvonderstirnwischt*

Sollte das ursprünglich falsch angekommen sein, dann verstehen wir uns hoffentlich jetzt :)

[Chris Lux]

Da die FXen von der Hardware her Float-Texturen weder filtern noch mipmappen können, wäre der Support von ATI_texture_float theoretisch zwar möglich, aber grösstenteils nur über Software-Fallbacks, und die will ja im Grunde sowieso keiner haben. HW-beschleunigt wäre es nur dann, wenn man genau die Untermenge trifft, die durch NV_float_buffer gebildet wird ...

Dann kann man auch gleich auf ATI_texture_float verzichten, und nur das offenlegen was die Hardware sowieso kann.
das ist scheinbar allgemein falsch angekommen. float_buffer war nur gedacht um pbuffer mit höherer präzision zu erhalten. um diese dann als eingabe nutzen zu könne ist das fp texture format für rects noch mit als nebenprodukt abgefallen. sie waren an sich nie als _echte_ texturen gedacht. jetzt rückt man bei der gf6 mit echten fp texturen nach. wobei ich mich dabei wieder frage wie man herausbekommen soll welche fp formate nun das filtern usw. unterstützen. laut nvidia geht das ja nur mit den fp16 formaten. die ATI_texture_float spec macht aber über solche einschränkungen keine aussage.


Alles nur der Vollständigkeit halber ;)
*schweißvonderstirnwischt*

Sollte das ursprünglich falsch angekommen sein, dann verstehen wir uns hoffentlich jetzt :)

na klar :uhippie: und gute nacht ;)