Khronos Group geeft OpenGL 4.5 vrij en begint ontwikkeling low-level api

De Khronos Group heeft OpenGL 4.5 vrijgegeven met enkele optimalisaties. Verder heeft de organisatie aangekondigd te werken aan een 'low-level api' die de strijd moet aangaan met AMD's Mantle en Direct3D 12. Ook is de gpgpu-taal Spir 2.0 vrijgegeven.

Eerdere OpenGL-specificaties kunnen het voor ontwikkelaars omslachtig maken om te werken met objecten, zoals textures. Zo zijn er diverse stappen nodig om een texture te genereren, te beschrijven en te manipuleren. Met de komst van direct state access in de officiële OpenGL 4.5-specificatie kan de status van een object direct opgevraagd en gemanipuleerd worden, waardoor het schrijven van code wordt vereenvoudigd. Daarmee maakt OpenGL een inhaalslag, omdat bijvoorbeeld Direct3D dergelijke operaties al langer ondersteunt.

OpenGL 4.5 belooft developers ook betere mogelijkheden om te bepalen hoe instructies naar de hardware worden gestuurd. Daarvan moet vooral multi-threaded-code kunnen profiteren. Daarnaast biedt OpenGL 4.5 een betere beveiligingslaag, iets waarvan met name WebGL-code kan gaan profiteren, en er is compatibiliteit met de OpenGL ES 3.1-api.

De Khronos Group heeft ook de Spir 2.0-specificatie aangekondigd, een programmeertaal voor gpgpu-toepassingen. Dit alternatief voor OpenCL vereist niet langer code die sterk lijkt op C, maar Spir 2.0 moet developers in staat stellen om code te schrijven in andere programmeertalen, zoals Python of javascript. Vervolgens wordt de code door de compiler voor deze programmeertaal omgezet in Spir-code, waarna de OpenCL-runtime deze verwerkt.

De organisatie heeft ook aangegeven dat het een low-level cross-platform-api wil introduceren in antwoord op de komst van AMD's Mantle, Apples Metal en de komende Direct3D 12-standaard van Microsoft. De Khronos Group heeft het Next Generation OpenGL Initiative opgericht om deze api te ontwikkelen.

Met de nog naamloze api moeten developers meer controle krijgen over de gpu, waardoor de prestaties ten opzichte van bijvoorbeeld OpenGL moeten verbeteren. Bovendien heeft de Khronos Group de ambitie om de low-level api geschikt te maken voor zowel mobiele als desktopplatforms, waardoor derivaten als OpenGL ES niet langer nodig zijn. Op termijn moet de opvolger van OpenGL uitgroeien tot een breed gedragen en geheel open api voor 3d-toepassingen en -games.

Reacties (30)

[Verwijderd]

Is Mantle nu de aanzet dat andere partijen ineens toch ook maar verder gaan ontwikkelen of is dit iets wat al langer speelde?

[himlims_]

Mantle is wel leuk, maar wat ook erg leuk is, en dikke prestatie opleverd (mits juiste serie kaart) is Gallium3D. Daarmee kun je met de open-source driver > gpu instructies doorzetten. Dat maakt het mogelijk om via wine D3D instructies direct naar de gpu te zetten, zonder deze eerst te vertalen naar opengl (wat nu gebeurd)

The big difference is, that normally wine emulates Direct X 9 with OpenGL calls, it has tons of code to translate each DX 9 API function to the equivalent OpenGL calls. Using the hack that translation is removed

Dan krijg je bijv. Call-Of-Duty 3 op hoge grafische instellingen: https://www.youtube.com/watch?v=167wysjBtLM - voorheen was dit onmogelijk.

mijn interview; http://rootgamer.com/11403/news/directx-linux-gallium-driver

[DCK]

Wat heeft een nieuwe feature van de Linux graphics stack precies te maken met deze discussie over Mantle en low level graphics APIs?

_{Verder een erg interessante feature, maar dit lijkt vooral op het promoten van je eigen blog. "Mantle is wel leuk, maar ik wil nu over iets praten waar ik op mijn blog over heb geschreven".}

[Verwijderd]

Gallium3D heeft ook een low-level API, waarbovenop oa een OpenGL of een Direct3D 'state tracker' kan draaien.
Maar ook eventueel de nieuwe low-level OpenGL als die er gaat komen.

[johnbetonschaar]

Gallium3d is ook nog eens geen 'nieuwe feature' van de Linux graphics stack, het bestaat echt al jaren maar begint nu pas een beetje onder de aandacht te komen omdat er steeds meer behoefte is aan een soort van 'virtuele gpu drivers', zoals D3D direct mappen op een OpenGL state tracker, of OpenGL naar software rendering (bijvoorbeeld llvmpipe). Gallium3D op zich is geen driver, en Gallium3D levert zelf op geen enkele manier 'dikke performance winst' op, het is een driver framework dat het mogelijk maakt om GPU drivers te schrijven die niet per se direct met hardware interfacen (maar dat op zich wel zouden kunnen, sommige OSS GPU drivers werken volgens mij ook via Gallium3D).

Het idee om D3D te vertalen naar OpenGL (of vice versa) is overigens ook niet nieuw, VM software als VMWare en Parallels doen dit soort dingen ook al vrij lang, ook zonder Gallium3D (ik meen dat de laatste versies van VMWare wel Gallium3D met llvmpipe gebruiken voor de svga3d driver, om op die manier een gevirtualiseerde GPU te bieden die software rendering gebruikt).

Hoe dan ook totaal offtopic inderdaad...

Edit @Scalibq:
Je hebt gelijk ja, ik wist niet dat iemand inmiddels al een D3D state tracker had gemaakt die direct met Gallium3D praat. Voorheen had je bijvoorbeeld VMWare of Parallels drivers die letterlijk D3D calls naar OpenGL drivers vertaalden, wat dus omslachtig en traag is. Ik ging er van uit dat er nu een driver was die een D3D state tracker implementeerde die mapte naar een andere al bestaande OpenGL state tracker, die dan vervolgens met de hardware kon interfacen. Maar blijkbaar is het veel eenvoudiger dan dat ;-)

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 12:43]

[Verwijderd]

Volgens mij snap je Gallium3D niet helemaal 100%.
Het idee is zo:
OpenGL state tracker -> low-level Gallium3D driver -> hardware
Of ook:
D3D state tracker -> low-level Gallium3D driver -> hardware

In het geval van Wine kun je dan dus de vertaalslag van D3D naar OGL (en al de bugs die daarbij komen kijken) juist overslaan, en heb je in feite 'native' D3D drivers, net als onder Windows.

Het leuke is ook dat het low-level gedeelte en de state tracker niet eens OS-specifiek zijn.
Als proof-of-concept hebben ze ook een Gallium3D driver voor Windows gemaakt.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 12:43]

[Verwijderd]

Gallium3D? Nooit van gehoord, net opgezocht, dit is inderdaad een zeer interessant iets. Vanavond thuis eens verder lezen en leren erover. Dank je wel voor je post.

[ankhie]

Ik denk dat er al langer onderzoek werd gedaan maar dat dat in een stroomversnelling is gekomen met Mantle. Het is niet iets dat je in een paar maanden in elkaar zet vermoed ik

[Bliksem B]

Ik denk dat er al langer onderzoek werd gedaan maar dat dat in een stroomversnelling is gekomen met Mantle. Het is niet iets dat je in een paar maanden in elkaar zet vermoed ik

En volgens mij is AMD alleen maar blij met deze ontwikkeling, zoals ze ook voorheen gezegd hebben was dit ook gedeeltelijk het doel dat videokaarten directer kunnen worden aangesproken: nieuws: AMD: updates voor OpenGL en DirectX liggen in lijn met Mantle-visie. Natuurlijk is gedeeltelijk politiek geluk, omdat:
1. Mantle een reden is om een AMD videokaart te halen.
2. Games/applicaties die een minder zwaardere CPU vereisen ten gunsten komt voor AMD's eigen CPU's/APU's die nou eenmaal minder sterk zijn als die van AMD zelf Intel.

[Reactie gewijzigd door Bliksem B op 23 juli 2024 12:43]

[Woodski]

Die CPU's van AMD zijn minder als die van AMD ?

[Iblies]

AMD maakt gewoon deel uit van de Kronos group,
http://www.khronos.org/about

Wat frappant is,
is dat er sluipenderwijs steeds meer standaarden ontstaan. Khronos heeft dan OpenCL en opengl, nvidia is bezig met cuda, AMD heeft mantle, Microsoft schrijft direct3d voor,
en een beetje gpu ondersteunt een mix.

Niet echt bevorderlijk.

[Dragunov]

Is beetje zoals tussen de Xbox One en PS4 (zie nu de ondersteuning voor 3D), de ene kondigt het aan, de andere doet de release, het kan niet zijn dat zer zo gauw alles klaar hebben als de ene het aankondigt.

[Verwijderd]

Bij OpenGL hoor ik dit voor het eerst.
Ik sta er ook nogal sceptisch tegenover. Er zijn namelijk al vaker grote API-updates aangekondigd. Zo zou OpenGL 2.0 een 'next-generation' API worden, en bij 3.0 speelde dat verhaal weer.
Daar is uiteindelijk niets van terechtgekomen, en zowel OpenGL 2.0 als 3.0 werden niet veel meer dan de legacy API, met een stel extensions die binnen de core werden opgenomen.
Zie ook hier, voor meer info: http://www.tomshardware.c...pengl-directx,2019-2.html
En hier het originele voorstel van 3DLabs voor OpenGL 2.0: http://www.13thmonkey.org/documentation/misc/ogl2.pdf

[Reactie gewijzigd door Verwijderd op 23 juli 2024 12:43]

[Soldaatje]

Mooi als deze low-level api ook voor Linux beschikbaar komt! De anderen waarschijnlijk niet.

[Dark_man]

Misschien als onderdeel van Steam OS, dat zou een mooie aanvulling zijn voor Steam OS en het ook echt een console maken die games beter kan draaien.

[LongBowNL]

Mantle wordt wel degelijk naar Linux geport.
nieuws: AMD port Mantle naar Linux

[Verwijderd]

Mantle waarschijnlijk wel. Bron.

[DCK]

Dit zou inderdaad van meerwaarde zijn voor Linux, en vooral ook voor Android. Windows krijgt Direct3D 12, iOS krijgt Metal (en OS X misschien in de toekomst), maar voor desktop Linux en Android was er nog geen low level API. Althans, niet eentje die los van AMD-drivers zou werken.

[SuperDre]

Dit alternatief voor OpenCL vereist niet langer code die sterk lijkt op C, maar Spir 2.0 moet developers in staat stellen om code te schrijven in andere programmeertalen, zoals Python of javascript. Vervolgens wordt de code door de compiler voor deze programmeertaal omgezet in Spir-code, waarna de OpenCL-runtime deze verwerkt.

ofwel echt baat heb je er niet bij, beter om gewoon de huidige OpenCL standaard code te gebruiken, want waarom toch weer telkens ieder zijn eigen scheet, er komt daardoor teveel diversiteit waardoor een standaard ook weer IMHO om zeep ligt..

[CAPSLOCK2000]

ofwel echt baat heb je er niet bij, beter om gewoon de huidige OpenCL standaard code te gebruiken, want waarom toch weer telkens ieder zijn eigen scheet, er komt daardoor teveel diversiteit waardoor een standaard ook weer IMHO om zeep ligt..

SPIR is géén alternatief voor OpenCL maar deel van hetzelfde systeem. De OpenCL-standaard blijft gewoon bestaan (en wordt ook beheerd door Khronos).

OpenCL is niet zo geschikt voor gebruikers van scripttalen. Nu is de aanpak vaak om je code eerst naar OpenCL te (laten) vertalen en dan verder te verwerken. OpenCL is daar niet voor gemaakt waardoor dat proces niet heel prettig is. SPIR is een tussenlaag die wel gemaakt is om op die manier gebruikt te worden. SPIR wordt ook door OpenCL zelf gebruikt.

Het was:
Python -> OpenCL -> (interne tussenvorm) -> low-level code -> hardware

Het wordt:
Python -> SPIR -> low-level code -> hardware
én
OpenCL -> SPIR -> low-level code -> hardware

OpenCL blijft dus gewoon maar script-talen kunnen op een lager niveau inhaken zonder onhandige constructies.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 12:43]

[Maurits van Baerle]

Klopt, de ontwikkeling van SPIR 2.0 is juist goed voor OpenCL. Voorheen kon OpenCL alleen met C overweg. Dankzij SPIR (als tussenstap) komt OpenCL nu ook binnen handbereik voor developers die niet zo thuis zijn in C en meer ervaring hebben met scripttalen.

[Jogai]

Als bv. de js=>openCL omzetting goed werkt heb je er wel een grotere potentiele doelgroep. Indirect wordt dan de OpenCL standaard dus ook belangrijker.

[Verwijderd]

Mja.. Ik weet niet of je daar zoveel mee opschiet, eerlijk gezegd.

OpenCL is vooral voor massive parallel programmeren, en daarom een totaal ander concept dan sequentieel programmeren. Je algoritmetje is niet 1-2-3 omgezet naar 'OpenCL'..

OpenCL is ook een behoorlijke 'niche'. Ofwel voor een specialistische markt.
Een huis, tuin en keuken developer zal er niet veel mee opschieten om z'n code op een GPGPU te draaien.

Persoonlijk vind ik de OpenCL taal vrij duidelijk en eenvoudig. Het meeste denkwerk zit meer in het opzetten van het algoritme.

[Verwijderd]

Als ik het goed begrijp, is SPIR een soort bytecode: https://www.khronos.org/spir
Het is dus "Standard Portable Intermediate Representation".
Waarmee ze dus naar een vergelijkbaar systeem gaan als Direct3D (en Cuda ook, meen ik).
De driver krijgt dan alleen een SPIR-compiler. Je applicatie kan dan voorgecompileerde shaders in SPIR-bytecode gebruiken, of zelf van source compileren naar SPIR, in welke taal dan ook, zolang je er maar een compiler voor hebt die het naar SPIR kan omzetten.

[Jogai]

Op termijn moet de opvolger van OpenGL uitgroeien tot een breed gedragen en geheel open api...

De low-level api is toch niet direct een opvolger? Ik kan me voorstellen dat OpenGL de api gebruikt, maar die blijft dan toch gewoon als high-level api bestaan...

[Verwijderd]

Wel een opvolger, geen vervanger.
De huidige OpenGL-API zal moeten blijven bestaan voor legacy software, maar het is natuurlijk de bedoeling dat nieuwe software gebruik gaat maken van de nieuwe API.
Aan de high-level API zullen ze waarschijnlijk ook niet meer doorontwikkelen.

[Jogai]

Maar de high-level api is toch nog gewoon handig voor dingen die niet helemaal geoptimaliseerd hoeven te zijn? Als opengl er alleen nog maar als low-level api is dan wordt het nog minder gebruikt ben ik bang...

[Verwijderd]

Maar de high-level API is er toch ook al? Als het niet geoptimaliseerd hoeft te zijn, dan is de huidige OpenGL 4.5 toch meer dan genoeg?
Ik verwacht niet dat ze 2 APIs tegelijk bij gaan houden. Ze hebben het al moeilijk genoeg om 1 API up-to-date te houden.

[CAPSLOCK2000]

NVidia heeft gisteren al beta OpenGL 4.5 drivers gepubliceerd in 340.23.01. Het zal nog wel even duren voor het in de stabiele drivers zit maar wie wil kan er dus al mee aan de slag.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 12:43]

[Lonnni]

Ik vind het jammer om te zien hoe AMD inzake OpenGL elke keer achter loopt in driver functionaliteit/ kwaliteit ten opzichte van Nvidia. Je weet dat je een AMD kaart zich goed kan meten met Nvidia kaarten in Windows, maar op andere platformen is het niet zo gepolijst vergeleken met de concurrent.
Ik had gehoopt met de GCN architectuur dat ze schoon schip hadden kunnen maken op Linux en OSX

De laatste keren bij een nieuwe OpenGL update is het altijd Nvidia die de eerste publiek werkende implementatie heeft. Ik vraag me af of het een probleem is van resources, programmeer kennis, gebrekkige Q&A of slecht management bij AMD.