Khronos publiceert definitieve OpenCL 2.0-standaard

De Khronos Group, verantwoordelijk voor onder andere de OpenGL-standaarden, heeft de 2.0-specificatie voor OpenCL goedgekeurd. OpenCL 2.0 biedt onder andere verbeterde geheugentoegang en nieuwe manipulatiemogelijkheden voor afbeeldingen.

OpenCL is zowel een programmeertaal op basis van C++11 en C11 als een platform. De open standaard, die onder andere door Apple, Intel, Nvidia, Qualcomm en AMD wordt ondersteund, is bedoeld voor het parallel uitvoeren van berekeningen op cpu en gpu, ook bekend onder de noemer gpgpu. De OpenCL 2.0-standaard moet de twee jaar oude 1.2-specificatie opvolgen. Nadat in juli een draft-versie door de Kronos Group werd gepubliceerd, is na de input van derden een definitieve standaard opgesteld.

De OpenCL 2.0-standaard bevat diverse nieuwe mogelijkheden voor applicaties die de rekenkracht van gpgpu willen benutten. Zo kunnen de host- en device-kernels het virtuele werkgeheugen voortaan met elkaar delen, waardoor er snelheidswinst kan worden geboekt. Ook kunnen programmeurs voortaan gebruik maken van geneste parallele berekeningen en er is meer vrijheid bij het opstellen van functies.

Voor het manipuleren van afbeeldingen biedt OpenCL 2.0 ondersteuning voor srgb- en 3d-afbeeldingen. Ook kan tegelijkertijd naar data van een afbeelding worden geschreven en gelezen, en er kunnen op basis van OpenGL-textures afbeeldingen gegenereerd worden. Verder is er ondersteuning voor het Android-besturingssysteem.

Reacties (27)

[jj71]

Mooi, maar programmeurs kunnen dit pas echt gaan gebruiken als fabrikanten zoals AMD en nVidia dit ondersteunen in hun SDK's en drivers. De vraag is hoe lang dat duurt... nVidia lijkt zijn eigen CUDA nog altijd liever te willen ondersteunen dan OpenCL.

[FreezeXJ]

AMD ondersteunt het redelijk snel verwacht ik, Intel idem. Beide samen zijn goed op weg om marktaandeel te veroveren, vooral als je double-precision verwacht zonder gek veel geld uit te geven (de Titan heeft een redelijke double-snelheid, maar verder moet je het bij NVidia hebben van de Teslas a 3000 euro of meer). Verder... als je het principe doorhebt kun je vrij snel met de taal van de concurrent aan de slag.

Inhoudelijk: eindelijk atomic floats, en zelfs iets wat op mutexes lijkt (de atomic_flag commandos). Dat gaat het leven van programmeurs makkelijker maken... Verder allerlei optimalisaties als pipe-writes, printf (dat kon niet onder oude OpenCL, tot mijn frustratie... Moest je eerst een buffer maken en die dan uitlezen, terwijl het nu direct kan), en een setje constants. Uitstekende zaak, dit helpt GPGPU hard vooruit.

[vinx77]

AMD gaat deze SC vertellen of en wanneer ze OpenCL 2.0 gaan ondersteunen, heb ik viavia gehoord. Maar van Altera verwachtte ik ook wat 2.0-aankodigingen van, terwijl ze lekker op 1.0 blijven hangen.

Werk je nog steeds op OpenCL 1.1? printf zit namelijk al in 1.2, zie: http://streamcomputing.eu...tween-opencl-1-2-and-1-1/

Begrijp wel dat atomic floats een stuk trager zijn, dus gemak-voor-een-prijs.

[FreezeXJ]

Ik heb inderdaad vooral van 1.1 gebruikgemaakt ja, en de upgrade naar 1.2 is langs me heen geschoten

Atomics en mutexes komen altijd met een prijs, en zijn net als het GOTO-statement riskant. Ze kunnen nuttig zijn, maar misbruik wordt streng bestraft door een beroerde performance. Desnogwelteplus heb ik stukken code 2x moeten laten uitvoeren omdat ik anders mogelijke races kreeg (en 1 ding garandeer ik je, als races kunnen voorkomen, krijg je ze zeker met 2k threads naast elkaar... ). Dat kostte me meer performance dan een paar atomic_floatjes.

[vinx77]

Dan moet je wel dubbel blij zijn. NVIDIA ondersteunt alleen geen OpenCL 1.2, OSX pas sinds kort.

Races kan je trouwens checken op http://streamcomputing.eu/knowledge/tools/gpuverify/ (er komen meer tools aan).

[Verwijderd]

Link dan op zijn minst ook het origineel: http://multicore.doc.ic.ac.uk/tools/GPUVerify/

[Defiance]

AMD heeft de OpenCL standaard al lang in hun SDKs (voor zover ik weet tenminste).

Dit is de (bijvoorbeeld) 1 van de redenen waarom AMD kaarten nVidia vernietigt in OpenCL doeleinden, bijvoorbeeld het Brute Forcen van oude Linux wachtwoorden opgeslagen in MD5 Hash.

Maar wanneer het volledig in de wereld van de consument terecht komt is nog maar de vraag.

Komt helaas traag op gang.

[Ventieldopje]

Onzin, dat komt omdat AMD kaarten een andere architectuur hebben en heeft weinig tot niks te maken met OpenCL vs CUDA Zo is bijvoorbeeld het minen van bitcoins sneller op een AMD GPU omdat bitcoin gebruik maakt van SHA-256 hashes die zwaar leunt op de '32bit right rotate' functie, iets waar AMD GPU's qua ontwerp gewoon beter in zijn omdat ze dat in één instructie kunnen ipv. drie!

Nou schijnen ze met de introductie van de Titan en Tesla K20(X) dat min of meer opgelost te hebben dus is het gat wat kleiner

[Dykam]

Als ze het in één instructie kunnen ipv drie, is het toch een andere standaard die ondersteund wordt? Voor zover ik weet zou het een architektonisch verschil zijn als het één instructie in één cycle deed ipv drie.

[pauluss86]

Standaarden van high-level programmeertalen zitten boven de hardware.

Er kunnen wel verschillen zijn tussen de exacte implementatie op een bepaalde architectuur, maar de essentie blijft onveranderd. De C++ standaard is een voorbeeld van het laatste. Veel programmeurs (zeker uit het Java 'kamp') gaan er ten onrechte van uit dat een integraal van type int altijd 32-bits is en een long 64-bits. De enige garantie die je hebt is dat een long (qua bits) even groot of groter is dan een int.

Ander voorbeeld, een 'integer X vermenigvuldigen met 2' kan geïmplementeerd worden zonder daadwerkelijk te hoeven vermenigvuldigen: X+X of X << 1 geven hetzelfde resultaat (overflow buiten beschouwing gelaten). Beiden voldoen aan de 'standaard specificatie' van vermenigvuldigen met 2.

[Defiance]

Misschien had ik het een beetje verkeerd verwoord.

Ik doelde simpelweg op het feit dat AMD dit al lang heeft in reactie tot jj71.

However ik weet niet tot hoeverre dit het verschil maakt in Brute Forcing van MD5 wachtwoorden vs. nVidia's CUDA.

De gat is nog steeds brutaal in het voordeel van AMD zelfs met de GK110 architectuur van nVidia.

Also.. MANY SMILIES! HANDLE IT!

[Maurits van Baerle]

Och, NVIDIA loopt soms een paar maanden achter als het op nieuwe OpenCL versies aankomt maar ze moeten het wel ondersteunen omdat de markt er om vraagt. Het zit ook al sinds 2009 standaard in hun drivers en SDK's. Als een systeembouwer of professioneel softwarepakket OpenCL vereist dan zou NVIDIA wel gek zijn om het niet te ondersteunen.

Nvidia.com: OpenCL | NVIDIA Developer Zone

[Reactie gewijzigd door Maurits van Baerle op 28 juli 2024 22:07]

[vinx77]

Ze lopen zelfs 2 jaar en 3 maanden achter, en ze gaan het ook niet beter ondersteunen als het aan hen ligt. Er is echter meer-en-meer druk vanuit de industrie en gebruikers, omdat OpenCL simpelweg een standaard is geworden. Zo uit mijn hoofd ondersteunen Intel, AMD, ARM, Imagination, Qualcomm, TI, Altera, XilinX, Adapteva en Vivante het nu - er zijn naar schatting nog ongeveer 3 processoren onderweg.

Als je wilt dat ze het gaan ondersteunen, teken dan deze petitie: http://www.ipetitions.com...l-examples-in-cuda-5-sdk/

[FreezeXJ]

Geen petitie tekenen, stemmen met je portemonee. Geen NVidia kopen Heel effectief! Ze komen vanzelf met functies die de concurrent veel winst opleveren, daar is het een bedrijf voor.

[Artimunor]

Hoe zou dit bruikbaar zijn binnen Android (openGL)?
Kan dit al met de huidige GLES20 of alleen met de huidige GLES30 of moet het nog in een toekomstige GLES40 ofzo beschikbaar gesteld worden?

Als het laatste het geval is gaat het nog een hele tijd duren voordat het ook in apps gebruikt gaat worden (zodra +/- 90% van de devices in de markt het ook ondersteund denk ik)

[FreezeXJ]

OpenGL is geen OpenCL, beide verschillen gruwelijk veel. CL is puur bedoeld voor rekenwerk, terwijl GL de grafische afdeling voor z'n rekening neemt. De extra functies die hier geboden worden zijn (bijna) nutteloos voor OpenGL.

[sotiri]

je kan OpenGL gewoon vergelijken als Windows zijn DirectX , OpenGL is een opensource engine voor grafisch omgevingen weer te geven in games in dit geval. linux heeft dit in alle os'en geïnstalleerd.

[Maurits van Baerle]

Je kunt OpenGL niet zonder meer vergelijken met DirectX. DirectX is een hele verzameling API's voor van alles en nog wat. Van 2D beeld, 3D beeld, Computing tot Geluid en Input.

OpenGL doet alleen beeld. Voor Computing moet je bij OpenCL zijn, voor geluid bij OpenAL enz.

Je zou hooguit OpenGL kunnen vergelijken met Direct3D.

[Reactie gewijzigd door Maurits van Baerle op 28 juli 2024 22:07]

[Nibbz]

of met Glide!!! (3DFX)

[johnkeates]

Of met Mantle!

[Gamebuster]

OpenCL is awesome. Ik heb recent me verdiept in OpenCL en heb diverse berekeningen erin geimplementeerd. Ik ben nu bezig om een game prototype te maken waarvan vrijwel alle berekeningen in OpenCL gebeuren en er direct naar OpenGL vertex buffers en textures geschreven worden om de communicatie tussen de CPU en GPU minimaal te houden en zo de overhead van gl* calls zoveel mogelijk te omzeilen.

De performance zover was enorm. Ik kon bij al mijn game prototypes die ik tot nu toe gemaakt heb niet meer dan zo'n paar 1000 bewegende entities in beeld krijgen, hoeveel moeite ik ook deed. Met OpenCL heb ik in mijn 1e poging over de 100.000 bewegende entities met 60fps in beeld gekregen op verouderde midrange hardware (nvidia 9400M GS 256MB).

Ik gebruik OpenCL 1.0 in LWJGL in Java 1.7 op mijn macbook.

[Reactie gewijzigd door Gamebuster op 28 juli 2024 22:07]

[Verwijderd]

Ik moet eerlijk zeggen dat ik niet heel vele verstand heb van OpenCL, maar wordt het niet een probleem als je een grafisch zeer zware game hebt? Dan wil je toch eigenlijk de GPU zoveel mogelijk inzetten voor grafische berekeningen?

[vinx77]

Je kan berekeningen op pixels door OpenGL shader-language laten doen, maar je kan ze ook overgeven aan OpenCL. wordt vaak naar verwezen als "GLCL-interop". Ik heb de afgelopen jaren flink wat info verzameld, dus ik denk dat ik je wat op weg kan helpen met wat OpenCL kan.

Een wat verouderde beschrijving staat hier, maar de video spreekt boekdelen: http://streamcomputing.eu/knowledge/what-is/opencl/

Wat voor soort berekeningen je ermee kan versnellen: http://streamcomputing.eu/knowledge/will-opencl-work-for-me/

Zie hier 13 soorten berekeningen die het goed doen met OpenCL: http://streamcomputing.eu...areas-opencl-can-be-used/

[Gamebuster]

Ik heb al sinds 2010 het idee om een game te maken die grafisch gezien niets bijzonders is (2D of simpele 3D graphics) maar waar het vooral draait om grote hoeveelheden aan bewegende objecten in de wereld en in beeld.

De simulatie van de wereld en de rendering ervan is relatief simpel, maar de aantallen wil ik op z'n minst in de 10.000 in-world kunnen hebben, het liefst ook on-screen. Ideaal voor OpenCL met OpenGL memory sharing.

Het uiteindelijke (zeer ambitieuze) plan is een MMO RTS, maar omdat ik het puur als hobby doe wil ik het eerst opzetten als simpele tower-defense game en dan geleidelijk steeds opbouwen en complexer maken.

Grafisch gezien gebruik ik nu een space-invaders-like setting. Wat stipjes die sterren voorstellen en wat super simpele pixelart-spaceships.

[Reactie gewijzigd door Gamebuster op 28 juli 2024 22:07]

[SG]

ja veel games zijn meer gpu afhankelijk. Maar heden is er nog weinig gpgpu gebruik of iig niet voldoende hoog opgeschaald.

Het belangrijkste is dat je de hardwre dt je beschikbaarhebt optimaal gebruikt.

Dus wat is je seriele cou power vs masive concurent gpu power.

Is dat redelijk in verhouding dan kan je code goed splitsen in seriele branch heavy code voor de zware cpu cores. En alles concurrent naar de GPU toe.

Maar is je ratio niet optimaal voor de software dan moet code flexible genoeg zijn om werk te shiften.


Ipv idle CPU kan je die ook wat concurent taken laten doen als je gpu te licht is.

Zelf hou ik dit aan als je game maakt die grote hoeveel of masive concurent tasks heeft. En daar GPGPU voor wilt gebruiken omdat beter en efficenter voor die task is.
Zoals massive amount of units waar je hun AI berekend van 1000+.

dan stel je de minimum en tecommended gpu spect bij naar boven.

Een game prototype om AI en gameplay te ontwikkelen is goed idee. Maar de next fase is up ook grafisch voor iets meer gaan. Dan groeien de hardware eisen mee dat is normaal.

Goed voorbeeld is dat cuda physX. Meeste games gebruiken cpu dus niks bijzonders. Enkele gebruiken ook de gpu voor gpgpu physics maar dan sloot meer physics dit houd in dat je gpu moet kiezen dat het door effect physics extra zware gfx load aankan en reserves voor gpgpu gebruik dat deze dus wat zwaardere gpu eisen heeft.
Houd ook niet in dat cheap cpu voldoet. Want er wordt meer gedaan door die ene gpu die moet meer doen in frame time dus cheap cpu mag daar ook niet te veel van weg snoepen.
Dus redelijke cpu toch altijd nodig.

Zware physx games hadden veel baad bij snelle cpu en dedicated render gpu en dedicated gpgpu kaart.

Geld uiteraard niet voor ontlasten van lichte normale mainstream cpu load.

[privateplaces]

https://www.khronos.org/n...r-heterogeneous-computing

[Reactie gewijzigd door privateplaces op 28 juli 2024 22:07]

[.Peter.]

Blijkbaar is http://www.khronos.org/opencl/ nog niet bijgewerkt, maar OpenCL 2.0 lijkt wel degelijk af volgens dit persbericht: https://www.khronos.org/n...r-heterogeneous-computing

"November 18th 2013 – SC13 - Denver, CO – The Khronos™ Group today announced the ratification and public release of the finalized OpenCL™ 2.0 specification"

[Reactie gewijzigd door .Peter. op 28 juli 2024 22:07]