OpenGL 3.1 / GLSL 1.40 standaard gereleased

[The Flying Dutchman]

Eergisteren heeft Khronos een nieuwe OpenGL standaard gereleased met versienummer 3.1, daarbij is ook een nieuwe versie van de GL shading language (GLSL) gereleased met versienummer 1.40.

De specificaties zijn hier in te zien:
specificatie OpenGL 3.1
specificatie OpenGL 3.1 met ARB_compatibility extensie
specificatie OpenGL shading language 1.40

De aankondiging van Khronos:
http://www.khronos.org/ne...-opengl-3.1-specification

Zoals sommigen wel zullen weten is in september 2008 OpenGL 3.0 gereleased. Deze release kwam een stuk later dan in eerste instantie de bedoeling was, daarnaast bevatte OpenGL 3.0 geen complete API rewrite zoals eerder beloofd was. Wel werd het deprecation model ingevoerd, dat vrijwel alle fixed pipeline functionaliteit deprecated maakte. Ook werden een fiks aantal extensies tot de core toegevoegd waardoor DirectX 10.0 hardware een vereiste werd om OpenGL 3.0 te kunnen draaien. Voor het oude OpenGL 2.1 werden nieuwe extensies toegevoegd om functionaliteit uit OpenGL 3.0 ook op oude hardware te kunnen gebruiken die wel OpenGL 2.1 capable was, maar niet OpenGL 3.0 capable (uiteraard gold dit niet voor functionaliteit die alleen beschikbaar was op DirectX 10.0 hardware).

Nu, negen maanden later is OpenGL 3.1 gereleased. Wat is er nu veranderd (deze lijst is niet compleet)?

• Deprecated functionaliteit is verwijderd en is alleen nog maar beschikbaar via een extensie genaamd `ARB_compatability', hardware fabrikanten mogen zelf weten of deze extensie beschikbaar zal zijn in hun drivers.
• Er is een uniform buffer toegevoegd waarin uniform varialbelen voor shader programma's opgeslagen kunnen worden. Deze buffer kan gebruikt worden door meerdere shader programma's en maakt het een stuk eenvoudiger om variabelen mee te geven aan shader programma's. Ook heb je hierdoor minder cpu calls nodig om een serie uniforms te enablen/disablen.
• Instancing, het eenvoudig tekenen van meerdere dezelfde objecten.
• CopyBuffer, om eenvoudig en snel data van de ene buffer naar de andere buffer te kopieren. Bijvoorbeeld handig voor programma's die data delen met OpenCL.

nVidia heeft al een beta driver gereleased die OpenGL 3.1 zou moeten ondersteunen. Of dit ook daadwerkelijk werkt weet ik niet (op een forum zag ik iemand posten die zei dat het nog geen echte 3.1 drivers waren, hoe het precies zit weet ik niet). AMD heeft blijkbaar gezegd dat hun volgende driver release OpenGL 3.1 zal ondersteunen.

Ik ben best wel enthousiast over deze ontwikkeling. Ik had niet verwacht nu al een nieuwe versie van OpenGL te zien en ik had zeker niet verwacht dat alle deprecated functionaliteit nu alleen nog via een extensie beschikbaar zou zijn. Persoonlijk begin ik de indruk te krijgen dat de OpenGL 3.x series een tussenstap zijn naar de (eerder beloofde) nieuwe API, die backwards compatability zal breken.

Een aardige blogpost van Paul Martz hierover is vinden op:
http://www.skew-matrix.com/bb/viewtopic.php?f=3&t=4

Persoonlijk kijk ik er wel naar uit om deze schone OpenGL versie te gaan gebruiken, hopelijk binnenkort in combinatie met OpenCL. Wat denken jullie, is Khronos met OpenGL 3.1 weer op het juiste pad geslagen? Maakt OpenGL weer een kans om een moderne api te worden die kan concurreren met DirectX?

[roy-t]

De copy-buffer lijkt me wel een aardige toevoeging. Maar volgens mij mist OpenGL nog steeds die "edge" op DirectX. Dat zou juist verbeteren door een nieuw model dat zelfs OOP achtig zou moeten zijn, maar zover ik nu zie is dat nogsteeds niet gebeurt en is 3.1 eigenlijk openGL2.x met wat feature swaps. Nogsteeds geen rewrite, niets revolutionairs. Maar misschien nogsteeds een erg solide API.

Er is nog hoop voor openGL, zeker nu het sneller lijkt te gaan! Maar ik denk dat OpenGL vooral een alternatief voor DirectX zal zijn in omgevingen waar DirectX wat zwakker is, omdat het in sommige situaties handiger/beter is. (Linux/Low-resource niches, kleine programma's met wat extra 3D functionaliteit (aangezien OpenGL nogsteeds het image heeft dat het snel is op te zetten).

DirectX blijft denk ik de komende tijd wel de dominante speler op de (Windows) game markt.

[The Flying Dutchman]

Je hebt gelijk in dat er nog steeds geen nieuwe, OOP achtige API is. Maar persoonlijk geloof ik dat OpenGL 3.1 de weg daarvoor wel vrij maakt. Alle oude fixed pipeline functionaliteit is alleen nog maar bereikbaar via een extensie. Wat nu nog in OpenGL 3.1 zit is functionaliteit die er helemaal op gericht is om eenvoudiger goed presterende programma's te schrijven (doordat programmeurs niet meer de keuze hebben uit oude fixed pipeline functionaliteit die wellicht helemaal niet zo goed geoptimaliseerd is in drivers, omdat het toch weinig wordt gebruikt).

Kortom: OpenGL 3.1 is een schone OpenGL, de volgende logische stap is een nieuwe API. Of dat ook daadwerkelijk komt... afwachten maar natuurlijk. In ieder geval lijkt het erop dat Khronos zich er nu op richt om iedere 6 maanden een nieuwe OpenGL versie te releasen, als ze dat voor elkaar hebben, dan zit er in ieder geval niet meer die jarenlange stilstand in zoals we die zagen na versie 2.1.

[Verwijderd]

OpenGL 3.1 is een paar dagen geleden uitgegeven, en het lijkt er op dat een hoop van de dingen die al in versie 3.0 beloofd waren, er nu eindelijk in zitten. Het idee van deprecation en evolutionaire vernieuwing begint nu eindelijk vruchten af te werpen. Gezien de enigszins teleurstellende belangstelling lijkt het erop dat het toch echt 'too little, too late' is, maar voor degenen die vast zitten aan OpenGL (cross-platform, bestaande code-base), of die nog geen noodzaak hebben gevonden om over te stappen, is het mooi nieuws.

Nvidia heeft meteen op de dag van uitgeven al een driver beschikbaar gemaakt die overweg kan met deze nieuwe specificatie. AMD belooft ook gauw met een driver te komen.

quote: http://www.khronos.org/ne...opengl-3.1-specification/

OpenGL 3.1 introduces a broad range of significant new features including:

* Texture Buffer Objects - a new texture type that holds a one-dimensional array of texels of a specified format, enabling extremely large arrays to be accessed by a shader, vital for a wide variety of GPU compute applications;
* Signed Normalized Textures – new integer texture formats that represent a value in the range [-1.0,1.0];
* Uniform Buffer Objects - enables rapid swapping of blocks of uniforms for flexible pipeline control, rapid updating of uniform values and sharing of uniform values across program objects;
* More samplers – now at least 16 texture image units must be accessible to vertex shaders in addition to the 16 already guaranteed to be accessible to fragment shaders;
* Primitive Restart – to easily restart an executing primitive, useful for efficiently drawing a mesh with many triangle strips, for example;
* Instancing - the ability to draw objects multiple times by re-using vertex data to reduce duplicated data and number of API calls;
* CopyBuffer API – accelerated copies from one buffer object to another, useful for many applications including those that share buffers with OpenCL™ 1.0 for advanced visual computing applications.

Wat vinden we ervan?

[Zoijar]

352 paginas, ik ben ze nog aan het lezen (toevallig sinds gisteren)

Ik vind het wel goed, maar het gaat wel aardig wat tijd kosten om code te porten. Ik hoop dat de copyBuffer API snel is, en niet zoals die cudaGlMapBuffer oid. Verder ben ik erg te spreken over de nieuwe buffer formaten; dat was altijd het meeste gedoe om die goed te krijgen. Nu heb je gewoon 1, 2, 3 en 4 component formaten in alle types die standaard zijn.

Verder zijn veel dingen natuurlijk gewoon rechtstreeks uit extensies geplukt, dus die gebruikte ik al lang. maar altijd mooi dat het nu standaard is.

Wat ik een beetje eng vind is dat de matrix stack weg is, dat gebruikte ik veel. ik heb nog niet gelezen hoe je dat nu dan moet doen, maar ik neem aan gewoon zelfs een matrix naar je shader pushen?

[ Voor 14% gewijzigd door Zoijar op 27-03-2009 11:09 ]

[Woy]

Hier liep al een topic over int SEA dus ik merge hem daarheen

[.oisyn]

Zoijar schreef op vrijdag 27 maart 2009 @ 11:07:
Wat ik een beetje eng vind is dat de matrix stack weg is, dat gebruikte ik veel. ik heb nog niet gelezen hoe je dat nu dan moet doen, maar ik neem aan gewoon zelfs een matrix naar je shader pushen?

Een matrix stack klinkt ook wel heel erg fixed function. Nou heb ik niet zo'n verstand van OpenGL's vertex shaders, maar in DirectX zijn er geen standaard model / world / projection matrices in de niet fixed function pipelines en moet je die dingen gewoon maar zelf in vertex constants proppen als je ze nodig hebt.

Oh, en kan The Flying Dutchman geen kortere nick nemen? Het verneukt de forum layout

[ Voor 7% gewijzigd door .oisyn op 27-03-2009 11:56 ]

[The Flying Dutchman]

Woy schreef op vrijdag 27 maart 2009 @ 11:50:
Hier liep al een topic over int SEA dus ik merge hem daarheen

Ik vroeg me al af waarom iemand al mijn info aan het herhalen was .

Zoijar schreef op vrijdag 27 maart 2009 @ 11:07:
352 paginas, ik ben ze nog aan het lezen (toevallig sinds gisteren)

Als je al bekent bent met OpenGL, dan zijn secties E (deprecation model), F (version 3.0 and before) en G (version 3.1) het interessants denk ik.

.oisyn schreef op vrijdag 27 maart 2009 @ 11:55:
[...]

Een matrix stack klinkt ook wel heel erg fixed function. Nou heb ik niet zo'n verstand van OpenGL's vertex shaders, maar in DirectX zijn er geen standaard model / world / projection matrices in de niet fixed function pipelines en moet je die dingen gewoon maar zelf in vertex constants proppen als je ze nodig hebt.

Dat is nu in OpenGL ook zo, je moet de matrices zelf in de shader proppen. Voorheen was het zo dat er een variabele standaard in de shader aanwezig was die de belangrijke matrices bevatte. Vergelijk het met als je Cg gebruikt ipv GLSL, daar moet je ook de matrices zelf naar de shader pushen.

Daarnaast zul je inderdaad zelf je eigen matrix stack op de cpu moeten implementeren. Over het algemeen zijn heel erg standaard functies waar je veel informatie over op internet kunt vinden.

.oisyn schreef op vrijdag 27 maart 2009 @ 11:55:
Oh, en kan The Flying Dutchman geen kortere nick nemen? Het verneukt de forum layout

Ja, je hebt helemaal gelijk. Ik meen me te herinneren dat ik hierover al eens contact had gehad met de admins, hoewel ik het niet meer zeker weet... in ieder geval is een nickchange er blijkbaar nooit van gekomen .

2e edit: firefox onder Linux is de layout niet verneukt trouwens .

[ Voor 13% gewijzigd door The Flying Dutchman op 27-03-2009 12:07 ]

[Zoijar]

The Flying Dutchman schreef op vrijdag 27 maart 2009 @ 12:02:
Daarnaast zul je inderdaad zelf je eigen matrix stack op de cpu moeten implementeren. Over het algemeen zijn heel erg standaard functies waar je veel informatie over op internet kunt vinden.

Het implementeren op de CPU is niet complex, daar gaat het me niet zozeer om. Ik heb code die zo veel mogelijk op bestaande opengl programmas draait als extra layer, en die leest opengl state uit. Oa om de huidige projectie en modelview matrices op te halen en die aan te passen en te gebruiken. Die lijn van programmeren valt weg; nu zal de client applicatie zelf die state door moeten geven. Het is wel op te lossen, het vergt alleen wat herschrijf werk...

Verder ben ik trouwens niet zo onder de indruk hoor; opengl 3.1 voegt volgens mij niets toe behalve copy buffers? Alles was er al lang, soms jaren, in extensies. Overigens zie ik ook de edge van directx niet hoor (zonder me in een holy war te begeven...); opengl heeft altijd al veel eerder support gehad voor alle hardware functionaliteit, en dat zal ook wel zo blijven. Dat is niet zo gek, want directx moet een geheel nieuwe core versie uitgeven met nieuwe features, terwijl opengl er gewoon een extension voor kan releasen. Verder zie ik niet zo veel verschil tussen core opengl en opengl met arb extensions. Voor mij hoeft het geen OOP API te worden; daar kan je wel wrappers voor schrijven als je dat wilt. De C stijl van de API in combinatie met extensions geeft je juist het gevoel dicht op de hardware te werken en er het meeste uit te kunnen halen.

The Flying Dutchman schreef op vrijdag 27 maart 2009 @ 12:02:
Als je al bekent bent met OpenGL, dan zijn secties E (deprecation model), F (version 3.0 and before) en G (version 3.1) het interessants denk ik.

Ik lees het snel door; ik ben bekend met 2.1 en alle ARB en NV extensions, dus ik wil eigenlijk alleen weten wat er precies deprecated is en hoe de extension functionaliteit nu in core GL heet, en of er nog verschillen zijn. Het zal allemaal wel wat gestroomlijnder werken nu. Dat is een groot pluspunt. Hiervoor verwees elke extension naar 5 andere en werkte dan toch weer net niet goed samen met een van die.

The Flying Dutchman schreef op donderdag 26 maart 2009 @ 12:53:
Een aardige blogpost van Paul Martz hierover is vinden op:
http://www.skew-matrix.com/bb/viewtopic.php?f=3&t=4

Lees je ook de open scene graph mailing list?

[ Voor 23% gewijzigd door Zoijar op 27-03-2009 14:22 ]

[The Flying Dutchman]

Zoijar schreef op vrijdag 27 maart 2009 @ 14:11:
[...]

Het implementeren op de CPU is niet complex, daar gaat het me niet zozeer om. Ik heb code die zo veel mogelijk op bestaande opengl programmas draait als extra layer, en die leest opengl state uit. Oa om de huidige projectie en modelview matrices op te halen en die aan te passen en te gebruiken. Die lijn van programmeren valt weg; nu zal de client applicatie zelf die state door moeten geven. Het is wel op te lossen, het vergt alleen wat herschrijf werk...

Klopt, het zal inderdaad wat aanpassingswerk vergen.

Verder ben ik trouwens niet zo onder de indruk hoor; opengl 3.1 voegt volgens mij niets toe behalve copy buffers? Alles was er al lang, soms jaren, in extensies. Overigens zie ik ook de edge van directx niet hoor (zonder me in een holy war te begeven...); opengl heeft altijd al veel eerder support gehad voor alle hardware functionaliteit, en dat zal ook wel zo blijven. Dat is niet zo gek, want directx moet een geheel nieuwe core versie uitgeven met nieuwe features, terwijl opengl er gewoon een extension voor kan releasen. Verder zie ik niet zo veel verschil tussen core opengl en opengl met arb extensions. Voor mij hoeft het geen OOP API te worden; daar kan je wel wrappers voor schrijven als je dat wilt. De C stijl van de API in combinatie met extensions geeft je juist het gevoel dicht op de hardware te werken en er het meeste uit te kunnen halen.

Ik ben voornamelijk onder de indruk van het snelle releasen van versie 3.1 na versie 3.0. Daarnaast ben ik ervan onder de indruk dat men toch daadwerkelijk alle deprecated functies van versie 3.0 nu uit de core heeft gehaald en in een extensie heeft gestopt. Khronos voegt dus de daad bij het woord, daarover had ik nogal mijn twijfels na alles wat er rondom OpenGL 3.0 gebeurt was... Verder maakt het mij ook niet bijzonder veel uit of OpenGL nu een OOP API heeft of niet, hoewel OOP vaak wel wat moderner aanvoelt. Overigens die uniform buffer die toegevoegd is lijkt me toch wel fijn hoor, betekend dat het gewoon makkelijker is om met uniforms in de shader programma's om te gaan en dat je minder cpu calls nodig hebt voor het verwerken van uniforms. Verder zijn voor gpgpu werk de non-normalized texture coordinaten ook best fijn om mee te werken lijkt me. Het zijn toch van die kleine dingetjes die het werken ermee net iets fijner en gemakkelijker maken.

Ik lees het snel door; ik ben bekend met 2.1 en alle ARB en NV extensions, dus ik wil eigenlijk alleen weten wat er precies deprecated is en hoe de extension functionaliteit nu in core GL heet, en of er nog verschillen zijn. Het zal allemaal wel wat gestroomlijnder werken nu. Dat is een groot pluspunt. Hiervoor verwees elke extension naar 5 andere en werkte dan toch weer net niet goed samen met een van die.

Ik denk persoonlijk ook dat dat het grote voordeel is. Als je naar versie 3.1 kijkt, dan zitten daar vrijwel alle functies in die je wilt gebruiken, maar geen overbodige zooi. Kortom, een schone API waar je goed mee kunt werken.

Lees je ook de open scene graph mailing list?

Nee, is dat de moeite waard? (de blogpost had ik gevonden via een ander forum).

[Zoijar]

The Flying Dutchman schreef op vrijdag 27 maart 2009 @ 15:08:
Verder zijn voor gpgpu werk de non-normalized texture coordinaten ook best fijn om mee te werken lijkt me. Het zijn toch van die kleine dingetjes die het werken ermee net iets fijner en gemakkelijker maken.

Dat kon wel al, hetzij via nv_texture_rectangle (flauw), maar ook met standaard textures had je in ieder geval een offset texel fetch in GLSL, op deze manier texture2DOffset(input_texture_2, index, ivec2(-1,0), die met integer pixel offsets werkt.

Ik denk persoonlijk ook dat dat het grote voordeel is. Als je naar versie 3.1 kijkt, dan zitten daar vrijwel alle functies in die je wilt gebruiken, maar geen overbodige zooi. Kortom, een schone API waar je goed mee kunt werken.

yep. Klinkt goed Ben het verder me je eens.

Nee, is dat de moeite waard? (de blogpost had ik gevonden via een ander forum).

Als je een VR scene graph API nodig hebt dan is OSG wel erg goed. Veel support voor input devices, verschillende vormen van stereo 3D, multi-/tiled-displays. Erg uitgebreid, open source, en een hele open en vrije mailing list met een snelle update cycle. Je kan allerlei patchen submitten en die worden vaak binnen een week of 2 in de source tree opgenomen.