A Khronos Group végre bejelentette az OpenCL régóta várt reformját. A nyílt specifikációjú GPGPU-s API jól kezdte a karrierjét, hiszen az OpenCL 1.2 megfelelő támogatásban részesült a piac részéről, de az OpenCL 2.0-val teljesen megváltozott a helyzet. Bár ettől a specifikációtól várták az áttörést, hiszen behozta az egységes memória támogatását, ezt viszont nagyon kevés gyártónak volt lehetősége megfelelően implementálni.
Az OpenCL 2.0 tehát végül nem áttörést, hanem hanyatlást eredményezett, ugyanis olyan követelményeket is megfogalmazott a rendszerek felé, amelyeknek sokan képtelenek voltak eleget tenni, egyszerűen nem rendelkeztek a megfelelő hardveres háttérrel. Ilyen formában az OpenCL 2.0 és ennek későbbi verziói nem váltak túl népszerűvé a programfejlesztés szempontjából, hiszen jelentősen kellett módosítani a korábban megírt kódokat, miközben a gyártói támogatás eléggé limitált volt. Ez már önmagában elég kellemetlen, és erre a gondra maguk a gyártók is rájöttek. Például az AMD rendelkezik egy olyan OpenCL implementációval is, amely lehetővé tett számos OpenCL 2.0-s funkció elérését az OpenCL 1.2-vel kompatibilis futtatási környezet mellett. Ez ugyan tudatos döntés volt a cég részéről, mert az OpenCL 2.0 alatt a futtatási környezet nagymértékben megváltozott, ami azt jelenti, hogy az aktuális programok modernizálása rengeteg erőforrást emésztene fel, miközben a specifikus implementációjukkal erre nincs szükség, de ezzel az előnnyel eltűnt a szabványosság is, ami egyébként az OpenCL fő célja lenne.
A Khronos Group a problémákat megvizsgálta úgy döntött, hogy újraindítja a rendszert. Na persze nem a legelejéről, de azt látni kell, hogy az OpenCL 1.2 volt az az utolsó specifikáció, amire a gyártók is figyeltek, megfelelő implementációk készültek hozzá, és a fejlesztői támogatás is kellemesnek tűnt.
Az új, OpenCL 3.0 esetében nem véletlen, hogy a nyers alapokat tekintve az OpenCL 1.2-re épül. Minden funkció, ami ezen túlmutat opcionális, ami azt jelenti, hogy bármelyik OpenCL 1.2-t támogató hardverre készíthető OpenCL 3.0-s implementáció. Maga az OpenCL 2.0 és az újabb verziók képességei sem tűntek el, hanem bekerültek a rendszerbe, de olyan opcionális funkciókként, amelyeket könnyen el lehet érni az új API-n belül. Ezek elérhetőségét a program oldalán le lehet kérdezni, és ha az adott implementációban van rá támogatás, akkor használhatók. Lényeges újítás az aszinkron DMA kiterjesztés, az OpenCL C 3.0 nyelv specifikációján belül megjelenő makrók, illetve a SPIR-V 1.3-on belül a subgroupok támogatása. Mindezeken túl az OpenCL C++ projektet leváltja a különálló C++ for OpenCL ökoszisztéma.
[+]
A változásokkal a Khronos Group gyakorlatilag abszolút a piaci igényekhez igazodik. Van egy alapvető funkcionalitás, ami kötelező, és itt igen nagy az egyetértés a gyártók, illetve a fejlesztők között. Ezen túlmenően minden opcionális, de nagyon fontos, hogy könnyen lekérdezhető formában, nem úgy, ahogy az OpenCL 2.0 biztosította a meglehetősen monolitikus dizájnjával, tehát az új funkciók elérhetőségéhez nem kell igazodni egy eltérő fő specifikációhoz. Ez leginkább a gyártóknak lesz könnyítés, ugyanis a legtöbben azért nem tudták implementálni az OpenCL 2.0-t, mert a felépítése mindent vagy semmit alapon dolgozott, tehát egy hardver hiába tudott volna támogatni egy funkciót, ha egy másikat lehetetlen volt hatékonyan megoldani rá. Ilyenkor a gyártók egy olyan kényszerhelyzetbe kerültek, hogy végül inkább az OpenCL 2.0 támogatásának a hiányát választották. Jó példa, hogy OpenCL 2.2-es implementációval senki sem rendelkezik, egyszerűen annyira kötött a specifikáció, hogy képtelenség normálisan támogatni a hardverek jó részén, de igazából az erőforrás befektetését sem éri meg, ha egyszerűen magát lövi lábon az API.
[+]
A fejlesztők számára jó hír, hogy az OpenCL 3.0 lényeges fejlesztési koncepciója volt a visszafelé kompatibilitás. A Khronos Group szerint egy megfelelően megírt alkalmazást gyakorlatilag a kód módosítása nélkül lehet OpenCL 1.2-ről 3.0-ra portolni. Az OpenCL 2.0 és újabb verziói esetében már egy trükkösebb a dolog. Ha az adott meghajtóimplementáció támogatja az összes, alkalmazás által használt funkciót, akkor nincs gond a portolással, szintén megoldható a kód módosítása nélkül. Ugyanakkor az alkalmazás oldalán érdemes átállni az opcionális funkciók lekérdezésére, ami kód hordozhatóságát. Ez sem egy megoldhatatlan probléma, de a kód módosítását igényli.
[+]
A jövőt tekintve a Khronos Group lényeges tervekkel rendelkezik, és ezeket az új dizájnfilozófiának köszönhetően könnyebb is lesz megvalósítani. A következő OpenCL-ben az egyik komoly újítás az úgynevezett flexibilis profilozás lesz, ami lehetővé teszi a gyártók számára, hogy az implementációjukat tényleg nagyon a hardverükhöz szabják. Ennek leginkább a beágyazott termékek piacán lesz értelme, mivel olyan profilt tudnak a cégek generálni, amellyel nem szükséges az egyes, amúgy kötelező érvényű követelményeket teljesíteni. Ergo, ha a hardvere esetleg nem tudna megfelelni az OpenCL minimum követelményeinek, akkor a profil módosításával megfeleltethető, vagy ha esetleg vannak olyan kötelezően támogatandó funkciók, amelyeket az adott piacon biztos nem használnának, akkor azok is kivehetők. Utóbbi az egész szoftveres hátteret segíti, hiszen kevésbé lesznek komplexek a meghajtók, a hitelesítés is egyszerűbb lesz, és hasonlók.
[+]
A flexibilis profilozás az OpenCL 3.0-nak az opcionális funkciókra vonatkozó dizájnját is kezeli, ami például problémás lehet. Többek között felmerülhetett már az olvasóban, hogy nem lesz túl átlátható, hogy melyik implementáció mit támogat, tehát effektíve csak a kötelezően előírt funkcionalitásra lehet igazán építeni. Ugyanakkor az egyes piacon résztvevő gyártók megegyezhetnek egy olyan flexibilis profilban, amit mindannyian kezelnek majd, és túlmutat az alapvető funkcionalitáson.
A Khronos Group továbbra is koncentrál arra, hogy nem minden platformon érhető el az OpenCL, és ilyenkor a nem natív implementációk jöhetnek szóba. Például létezik olyan projekt, amely az OpenCL-t implementálja a Vulkan, a DirectX 12, vagy éppen a Metal API-n. Ezeknek a projekteknek – főleg az utolsónak – kiemelt segítséget biztosítanak. Emellett az OpenCL és a Vulkan API-k közötti interoperabilitás számottevő szempont.
Az OpenCL 3.0 esetében egyelőre az előzetes specifikáció van kész, és most kezdődik az implementációk tesztelésére vonatkozó munka, aminek a része a véglegesítés is. Ez valószínűleg pár hónapon belül lezajlik, mivel nagyon sok szempontból felhasználhatók a meglévő kódbázisok, a gyártók számára sem lesz túl nehéz OpenCL 3.0-s implementációval előállni, ha már rendelkeznek legalább OpenCL 1.2-t támogatóval. Ilyen formában a specifikáció véglegesítése sem ütközhet majd túl sok problémába.
