OpenGL 3.2 aangekondigt op Siggraph 2009

[The Flying Dutchman]

Nadat twee weken geleden nVidia al een linux beta driver presenteerde die aangaf OpenGL 3.2 te ondersteunen ontstonden de eerste geruchten dat de nieuwe OpenGL specificatie wel eens tijdens Siggraph aangekondigt zou kunnen worden.

Gisteren heeft de Khronos Group (voornamelijk bestaande uit grote hardware fabrikanten en grote software bedrijven) inderdaad OpenGL 3.2 en GLSL 1.50 aangekondigt. De voornaamste veranderingen zijn:

• Er is nu een core profile en een compatibility profile: een OpenGL 3.2 driver moet minimaal de core profile ondersteunen. De compatibility profile bevat deprecated OpenGL functies.
• De geometry shader zit nu in de core waardoor ook AMD dit zal moeten implementeren.
• Er kan multisampling gedaan worden op textures (zodat multisampling nu ook gebruikt kan worden in een deferred shading engine).
• Er zijn fence objecten toegevoegd, waardoor betere synchronisatie tussen cpu en gpu mogelijk wordt.
• In GLSL kan nu tussen shaders (vertex -> geometry en geometry -> fragment) met interface blocks werken. Met behulp van een interface block kunnen een aantal variabelen samen een soort `struct' vormen die gebruikt kan worden voor communicatie tussen shader programma's.
• Een aantal nieuwe functies die het eenvoudiger maken om Direct3D programma's te porten naar OpenGL (zoals het kunnen kiezen of een pixel op (0, 0) of (0.5, 05) ligt).

Zie voor de officiele aankondiging hier:
http://www.khronos.org/ne...ase-within-twelve-months/

Specificaties:
OpenGL specificatie 3.2 core profile
OpenGL specificatie 3.2 comptibility profile
GLSL 1.50 specificatie

Voor een aantal blogs over nieuwe functionaliteit:
http://www.g-truc.net/#news0170
http://www.devklog.net/20...-3-2-officially-released/

Qua functionaliteit zit de OpenGL core nu ongeveer op DirectX 10.1 niveau (of het exact overeen komt weet ik niet). Ook is het veelbelovend dat de Khronos group nu voor de tweede keer binnen 6 maanden met een vernieuwde specificatie komt, wat laat zien dat men hard bezig is om OpenGL weer op niveau te laten komen. nVidia heeft altijd goede drivers geleverd, maar ook AMD drivers zijn nu op een heel behoorlijk niveau. Helaas is AMD niet zo snel als nVidia (de laatste officiele drivers van AMD maakten het voor het eerst mogelijk om een beta OpenGL 3.1 context te maken, de kans is vrij groot, gezien de ondersteuning van OpenGL 3.0 en 3.1, dat het een maand of 6 duurt voordat AMD drivers beschikbaar heeft voor OpenGL 3.2).

Hoe het precies zit onder OSX weet ik niet. Is er al OpenGL 3 support onder Snow Leopard? Het update programma van Apple ben ik ook niet echt bekend mee, dus ik weet niet of er een kans bestaat dat er tussendoor een driver update komt die OpenGL 3.2 zal ondersteunen.

Al met al ziet het er weer vrij goed uit. Er zijn wel dingen die nog steeds heel erg gewenst zijn bij developers, maar die zich nog niet in de core bevinden (seperate shader objecten om vrij vertex/geometry/fragment shaders te combineren zonder opnieuwe te hoeven linken, shader binaries en bindless graphics waarvoor al wel een nvidia extensie is). Maar zover ik begrijp is de functionaliteit nu op een vergelijkbaar niveau als DirectX 10.1 en is het nu eenvoudiger om te porten tussen Direct3D en OpenGL. Samen met het cross platform zijn van OpenGL (zodat DirectX 10.1 functionaliteit beschikbaar is onder Windows XP, Vista, 7, Mac OSX en Linux) en de verbeterde aandacht van de Khronos group, lijkt OpenGL nu een goede stap te hebben gezet om weer wat aantrekkelijker te worden voor de developers.

edit:
Op de OpenGL website is te zien dat men ook werkt aan OpenGL 3.2 reference pages. Erg nuttig, de oude reference pages gingen niet verder dan OpenGL 2.1

OpenGL BOF:
Vanmiddag van 4 tot 6 (New Orleans) is de OpenGL BOF, waar waarschijnlijk ook OpenGL 3.2 besproken zal worden. Ik weet niet of dit op de een of andere manier life te volgen is.

[The Flying Dutchman]

Zijn er geen tweakers die zich met OpenGL bezighouden?

Zelf ben ik bijna afgestudeerd, maar hou me in mijn vrije tijd (onder andere) bezig met het maken van een eigen computerspel (cross-platform). Dit project is waarschijnlijk een soort 10-jaren plan en staat nog heel erg in de kinderschoenen . Omdat ik voornamelijk onder Linux werk, is DirectX geen optie voor mij. Vandaar dat ik de ontwikkelingen op het vlak van OpenGL op de voet volg.

Zijn er nog andere tweakers die zich met OpenGL of computer graphics iha bezighouden?

[Soultaker]

Eigenlijk vind ik het wel interessant (dus ook jammer dat je topic nu een beetje verpietert) maar ik weet er ook niet zoveel vanaf dat ik veel zinnigs over te zeggen heb.

Een aantal nieuwe functies die het eenvoudiger maken om Direct3D programma's te porten naar OpenGL (zoals het kunnen kiezen of een pixel op (0, 0) of (0.5, 05) ligt).

Waarvoor maakt dit uit? Ligt een pixel niet altijd precies tussen (x,y) en (x+1,y+1)?

[.oisyn]

The Flying Dutchman schreef op zondag 16 augustus 2009 @ 11:58:
Zijn er nog andere tweakers die zich met OpenGL of computer graphics iha bezighouden?

Jawel, maar op m'n werk zijn we nog altijd met DX9 bezig, hoewel DX11 waarschijnlijk binnenkort wel bekeken gaat worden. En de PS3 gebruikt OpenGL ES, dus dat staat er ook weer los van. Dus nee, de ontwikkelingen omtrent OpenGL volg ik niet heel erg

Soultaker schreef op maandag 17 augustus 2009 @ 12:43:
Waarvoor maakt dit uit? Ligt een pixel niet altijd precies tussen (x,y) en (x+1,y+1)?

Het maakt uit om te bepalen of een pixel binnen een polygoon valt, en op welke plek de pixels gesampled worden. Als je in OpenGL een quad tekent van (0, 0) naar (3.25, 1) dan zullen er 3 pixels gevuld worden, gesampled op x-coordinaat 0.5, 1.5 en 2.5. In D3D vult diezelfde quad 4 pixels, gesampled op 0, 1, 2 en 3.

Dit soort dingen zijn met name van belang voor post processing effects (of generic shaders), waar je een 1:1 mapping van texels op pixels wilt hebben

[The Flying Dutchman]

Een stukje leesvoer dan, om even OpenGL met Direct3D te vergelijken (op zich is dit wel vaker aan bod gekomen, maar het blijft een interessante discussie denk ik):

Ik merk heel vaak dat veel mensen niet zoveel van OpenGL afweten. Zo denken mensen vaak dat je geen mooie graphics kunt maken met OpenGL omdat het op DirectX 9.0 zou lijken. Ja, als je alleen de core functionaliteit van OpenGL 2.1 pakt dan wel ja. Met behulp van extensies kom je echter al een heel eind richting DirectX 10 (als het qua functionaliteit niet gewoon op hetzelfde niveau zit). Zeker als je het over OpenGL 3.x gaat hebben, dat is qua functionaliteit gewoon vergelijkbaar met DirectX 10 en DirectX 10.1.

Ook als je kijkt naar hoe men reageert op een website als gamedev.net (die overigens z'n beste tijd gehad heeft denk ik, 75% van de mensen die daar op de forums komen weten helemaal niets en denken wel even zelf een game te maken), dan is het kennisniveau van OpenGL echt laag. Ook daar denkt men dat je alleen met DirectX een mooie game kunt maken.

Natuurlijk heeft OpenGL nadelen ten opzichte van Direct3D. Er is geen goede SDK, er is geen driver certificatie programma zoals dat er voor DirectX wel is (wat betekend dat hardware fabrikanten zelf verantwoordelijk zijn voor het testen van de drivers en dus meer kans op afwijkingen). En hoewel het extensie systeem een voordeel is (nieuwe functionaliteit op de hardware is beschikbaar zodra de fabrikant er een extensie voor gemaakt heeft, niet pas als er een nieuwe versie van DirectX beschikbaar komt), heeft het ook een nadeel: fabrikanten zijn niet verplicht om extensies in hun drivers te implementeren. En dat is dan ook iets wat vooral Ati in het verleden verzuimd heeft. Daarnaast is er Microsoft, die er natuurlijk meer belang bij heeft dat Direct3D op Windows goed ondersteunt wordt, dan dat OpenGL goed ondersteunt wordt (toen Windows Vista uitkwam wilde Microsoft eerst alle OpenGL calls onder Windows omzetten naar Direct3D calls, gelukkig is dit niet doorgegaan, want dit had de doodsteek voor OpenGL op het windows platform betekend).

Er zijn echter ook voordelen aan OpenGL:
Het is cross platform: OpenGL draait op alle Windows versies, Mac OSX en Linux. Dit betekend ook dat functionaliteit vergelijkbaar met die in DirectX 10.1 gewoon beschikbaar is onder Windows XP. De extensies die ik al noemde zijn daarnaast een ander voordeel. Eerlijk is eerlijk, hier houdt het ongeveer wel op met de voordelen van OpenGL.

De nadelen hebben er in de loop der jaren voor gezorgd dat er steeds minder aandacht was voor OpenGL, wat resulteert in minder prioriteit bij het maken van de drivers en het implementeren van extensies voor OpenGL. Tot overmaat van ramp heeft Khronos (de organisatie die OpenGL beheerd) lange tijd OpenGL niet gemoderniseerd. Dit komt gedeeltelijk omdat men de bedoeling had om de API in een modern jasje te steken, een complete rewrite van de OpenGL API (de manier van programmeren in OpenGL is eigenlijk al 15 jaar niet veranderd, dezelfde functies die 15 jaar geleden in OpenGL zaten, zijn nu nog steeds toegankelijk). Uiteindelijk stuitte dit op teveel weerstand en is men weer op het oude pad verder gegaan (extra extensies toevoegen aan de core om de basis functionaliteit verder op te vijzelen).

Toch denk ik dat er weer licht aan de horizon is.

OpenGL heeft het afgelopen jaar een forse ontwikkeling meegemaakt. In september 2008 heeft men OpenGL 3.0 gereleased, waarin een hoop van de oude functionaliteit deprecated werd. De eerste stap naar een moderne API, die niet al dat gewicht van 15 jaar verandering (en compleet andere hardware achitectuur ten opzichte van 15 jaar geleden) met zich meedraagt.

Zes maanden later (een record tijd voor OpenGL ontwikkeling) kwam OpenGL 3.1 uit. Zoals beloofd heeft men alle deprecated functionaliteit eruit gehaald. Hoewel die echter wel toegankelijk bleef via een extensie, voor ontwikkelaars die dat toch graag nog wilden gebruiken. Maar omdat de oude functionaliteit zich nu in een extensie bevind, zijn hardware fabrikanten niet meer verplicht om deze te ondersteunen in de drivers. Ook werd de API verder gestroomlijnd met toevoegingen die de functionaliteit dichter bij DirectX 10 brachten, het porten van DirectX naar OpenGL en vice versa gemakkelijker maakten en functionaliteit die er vooral op gericht was om het aantal bind calls die door de cpu uitgevoerd moeten worden te verlagen (zodat een applicatie minder snel cpu afhankelijk is).

Dezelfde stap werd weer zes maanden later nog eens herhaald met OpenGL 3.2. Nog meer verbeterde functionaliteit die past bij moderne hardware. De functionaliteit die zich in de core van OpenGL bevind is nu vergelijkbaar met DirectX 10 (dus onafhankelijk van extensies).

Een ander lichtpunt is dat sinds AMD Ati heeft overgenomen, er nu serieuzer werk wordt gemaakt van de drivers van AMD/Ati. Waar men vroeger steen en been klaagde (en terecht) over de Ati drivers, is het niveau hiervan tegenwoordig een heel stuk beter. Doordat Khronos het afgelopen jaar veel functionaliteit toegevoegd heeft, is AMD ook verplicht om deze functionaliteit toe te voegen aan hun drivers (als ze tenminste willen claimen dat ze OpenGL 3.x ondersteunen). De afhankelijkheid van fabrikanten, die zelf mogen kiezen of ze de extensies in hun drivers ondersteunen, is dus afgenomen doordat veel van de functionaliteit nu in de core van OpenGL zit.

Al met al is er dus een positieve ontwikkeling gaande omtrent OpenGL. Of dit zich doorzet hangt heel erg af van de toekomstige ontwikkelingen. Eigenlijk verwacht ik dat de gemoderniseerde API zich over een tijdje toch zal aandienen. Het zou me niet verbazen als Khronos in augustus 2010 (Siggraph 2010) OpenGL 4.0 aankondigt waarin we dan toch de object georienteerde api zullen zien. De tijd was er vorig jaar nog niet rijp voor, maar de ontwikkelingen van het afgelopen jaar lijken toch te wijzen op een breuk met het verleden, wat de weg vrij kan maken voor een moderne API.

Ook is het te hopen dat Khronos er voor blijft zorgen dat de functionaliteit zich aan blijft passen aan moderne hardware. Nu DirectX 11 hardware er aan zit te komen, is het belangrijk dat deze functionaliteit ook onder OpenGL beschikbaar wordt. Een deel van die taak is niet voor OpenGL maar voor OpenCL weggelegd. De compute shaders van DirectX 11 zullen we niet in OpenGL zien vermoed ik, dat is een taak voor OpenCL. Het is daarom ook belangrijk dat OpenCL zich ook blijft ontwikkelen en dat de twee API's goed met elkaar overweg kunnen.

[Verwijderd]

Een interessant verhaal! Ik had altijd de indruk dat OpenGL mijlen ver achterliep, maar als ik het zo lees ligt dat toch iets anders. Het is vrij lastig om er van de buitenkant achter te komen hoe het zit, DirectX vs. OpenGL valt een beetje in dezelfde hoek als Intel vs AMD, nVidia vs. AMD/ATi, C# vs Java, Windows vs Linux, etc. Daar kom je dus niet zo snel uit.

Stiekem krijg ik hierdoor inspiratie om zelf ook eens met DirectX en OpenGL te spelen. Alsof ik nog niet genoeg ideeën had die ik niet uitvoer (zie koffiehoek ).

[roy-t]

Even niet kijkend naar mijn 'ms fanboy' ondertitel (ik vind OpenGL EN DirectX bloedje interessant) heb ik ook het beeld nog dat OpenGL echt mijlen ver achterloopt, nu zijn er maar weinig mensen waarvan ik zeker van weet waar ze het over hebben. Maarja dan hoor je ineens van Carmack dat hij toch echt liever DirectX had gebruikt maar door ervaring nog bij OpenGL blijft.

Ook uit de eerste post met de changelog, volgens mij kan deffered rendered multisampling al sinds DirectX9, het staat nu een beetje als 'de grote verandering' misschien is dat onterecht en is het gewoon iets wat je eruit gepikt hebt.

Nu moet ik zelf toegeven dat ik bijna niet met OpenGL gespeeld hebt (windows dev dus ja, DirectX wel lekker makkelijk). En dat ik ook zeer positieve geluiden hoor (veel makkelijker met render states, en je hebt zo een kubus op je scherm) Maarja dat is natuurlijk niet al te relevant voor ingewikkelde games.

Ik hoop wel dat OpenGL echt weer op het niveau komt van DirectX, ten minste als de API zoals die nu heeft nu echt een goede kans heeft om door te blijven evolueren tot iets moois. Microsoft heet met DX10 die kans gegrepen om het echt even om te bouwen zowel intern in Windows als de API zelf en tot nu toe lijkt het alsof Kronos alleen maar functies deprecate en ze langzaam vervangt, is dat genoeg? Ik weet het niet. Maar 2 sterke manier om je videokaart aan te spreken is altijd beter dan 1, en DirectX4Linux zie ik nog niet zo snel gebeuren.

[Zoijar]

The Flying Dutchman schreef op zondag 16 augustus 2009 @ 11:58:
Zijn er geen tweakers die zich met OpenGL bezighouden?

Zijn er nog andere tweakers die zich met OpenGL of computer graphics iha bezighouden?

Ik ben altijd erg veel met OGL bezig.

The Flying Dutchman schreef op dinsdag 04 augustus 2009 @ 10:42:
• Er zijn fence objecten toegevoegd, waardoor betere synchronisatie tussen cpu en gpu mogelijk wordt.

Ik snap ook nooit zo dat vergelijk met DX. In het verleden is er altijd eerder support in OGL geweest voor nieuwe hardware dan in DX. Zodra er een nieuwe kaart of feature uitkomt released nvidia een extension. Al die nieuwe core 3.x releases hebben ook maar een paar dingetjes toegevoegd eigenlijk ten opzichte van OGL 2 + ARB en EXT extensies.

[ Voor 23% gewijzigd door Zoijar op 23-08-2009 10:45 ]

[roy-t]

Zoijar schreef op zondag 23 augustus 2009 @ 10:41:
[...]

Ik ben altijd erg veel met OGL bezig.


[...]

sweet

• Er zijn fence objecten toegevoegd, waardoor betere synchronisatie tussen cpu en gpu mogelijk wordt.

Hey wacht is even die heb ik gemist, hebben 'wij' dx-ers dat eigenlijk ook?

[Zoijar]

roy-t schreef op zondag 23 augustus 2009 @ 10:44:
Hey wacht is even die heb ik gemist, hebben 'wij' dx-ers dat eigenlijk ook?

Ik geloof dat jullie resources kunnen locken oid. Nou kon dat ook al in OGL met GPU geheugen buffers. Of je in DX de command pipeline kan syncen weet ik niet, maar het zal haast wel.

Veel mensen realiseren zich niet dat de OGL pipeline in principe niet geordend is als dat niet noodzakelijk is, en dat de GPU executie parallel loopt met de CPU. Als je naar een texture rendered en dan die texture met de CPU download naar systeem geheugen, dan zal je corrupted data krijgen, tenzij je de rendering fenced. Dat was ook hiervoor wel al mogelijk hoor, maar geen core. Ik gebruikte nvidia timer queries (occlusion query had ook gekund) omdat die intern een fence zetten. Er was ook een fence extension maar die werkte niet overal.

Ik heb veel werk gedaan met 2 GPUs in parallel op hetzelfde systeem die aan dezelfde scene aan het renderen zijn. Een low en een high priority kaart als het ware. Dat systeem heb ik ook timesliced op een enkele GPU gedraaid en dat was met oude driver vaak een hel. Ik hoop dus dat er nu betere support voor meerdere rendering threads op een enkele kaart komt.

[ Voor 16% gewijzigd door Zoijar op 23-08-2009 10:55 ]

[Sebazzz]

Voor mensen die trouwens cross-platform met .NET/mono een 3D game willen ontwikkelen, hier heb je het Tao OpenGL Framework voor. De samples zijn echter op deze computer niet erg stabiel