Nová verze OpenCL je návrat zpět a restart
OpenCL má jako poslední verzi OpenCL 2.2, ale tato verze vydaná v roce 2017 od té doby nezískala podporu žádného z výrobců GPU (Nvidie, AMD ani Intelu). Toto už asi ukazuje, že je momentálně OpenCL v problematické situaci. Rovněž už verze OpenCL 2.0 z roku 2013 nebyla zas tak populární a například embedded sféra nebo FPGA na ní nikdy nepřešly. Nová verze OpenCL 3.0 tak vlastně stojí před problémem, jak motivovat uživatele OpenCL nejen ho vůbec dál používat, ale také držet krok s jejím vývojem, na což někteří evidentně během OpenCL 2.0 až 2.2 rezignovali.
Z tohoto důvodu představuje nyní oznámené OpenCL 3.0 evoluci trošku nezvyklým směrem. Tato specifikace se vrací k původnímu OpenCL 1.2 z roku 2011 a bere si jako základ tento standard. A to zřejmě proto, že tato verze byla poslední, jejíž přijetí bylo mezi výrobci GPU a dalších akcelerátorů víceméně bezproblémové. Není to ovšem tak, že vše přinesené OpenCL 2.0 a následujícími verzemi během oněch devíti posledních let, bude hozeno do koše.
Vše po OpenCL 1.2 je odteď nepovinné
OpenCL 3.0 stanovuje základ v podobě technologií z OpenCL 1.2 jako to, co je povinná součást vyžadovaná pro podporu OpenCL 3.0. To znamená, že až na nějaké drobné přídavky a změny prakticky všechna OpenCL 1.2 zařízení (lépe řečeno kombinace zařízení a ovladačů) mohou být povýšena na podporu OpenCL 3.0. Nad to jsou pak přidané nové funkce, které zavedly standardy OpenCL 2.0 a pozdější, takže tyto technologie jsou zachovány. Ale všechny tyto věci už budou jen volitelné, takže výrobci je nemusí povinně umět.
Problémem u OpenCL 2.0 až 2.2 bylo zřejmě to, že jak měli různí participující hráči různé potřeby a představy, došlo k namnožení nejrůznějších funkcí a vlastností, které se všechny současně dostaly do standardu, ale jiné části dalších zúčastněných zase nevyhovovaly. V OpenCL 2.x ale byly povinné a to mělo paradoxně za následek, že firmy na novou verzi nepřešly kvůli velkému množství oněch nežádoucích novinek, které byly v balíku spolu s těmi žádnými.
Nyní budou všechny tyto post-OpenCL 1.2 funkce volitelné, takže je možné je dále používat, ale ti implementátoři, kteří je nechtějí zavést, už nemusejí. V praxi tedy musí ovladače hlásit, které funkce OpenCL 3.0 podporují, a program zase před použitím volitelných součástí musí zkontrolovat, jestli je hardware umí. Toto bude vyžadovat, aby se kontroly přidaly do všech OpenCL 2.x programů, než bude možné je prohlásit za kompatibilní s OpenCL 3.0. Aplikace napsané proti OpenCL 1.2 poběží na verzi 3.0 už úplně bez jakýchkoli komplikací.
Nastane fragmentace hardwaru
Znamená to ovšem, že známka o podpoře OpenCL 3.0 u hardwaru nebude zaručovat, že vám poběží všechny OpenCL 3.0 (a ani všechny OpenCL 2.0 či 2.1) programy. Ekosystém bude v tomto fragmentován a u softwaru se bude muset uvádět, na jakých GPU či jiných hardwarových cílech (FPGA, CPU) je program podporovaný. Ale za tuto cenu je zde opět šance, že se OpenCL jako standard poskytující alespoň nějakou společnou bázi udrží a bude se moci začít zase vyvíjet dál.
Víceméně je tedy OpenCL 3.0 částečně i servisní vydání, na které vývojáři aplikací mohou přejít relativně bez velké práce a výrobci hardwaru/ovladačů zase bez velkých úprav. Je třeba jen zajistit infrastrukturu pro kontrolu, které funkce z verzí 2.x hardware nabízí, ale není potřeba měnit samotné algoritmy.
Skutečné novinky: SPIR-V 1.3, odstranění C++
Má to i své výjimky. Je přidána úplně nová (a také volitelná) funkce Asynchronous DMA Extension, která asi nebude používána velkými GPU, měla by být určena pro embedded hardware a procesory.
Také je přidána podpora intermediate reprezentace kódu SPIR-V 1.3. Ani ta není povinná, ale SPIR-V je používáno v API Vulkan jako jazyk shaderů, takže jeho podpora by měla být užitečná pro interakci s grafickými operacemi ve Vulkanu.
Je také jedna výjimka z toho, že z funkcí verzí 2.x se staly volitelné doplňky. Podpora C++ kódu (objektového programování) z verze 2.2 byla úplně zrušena, nebude dostupná ani jako volitelný doplněk. OpenCL se tedy vrací k základu na jazyku C. Pokud by někdo chtěl C++ dál využívat, bude to možné skrze externí open-source projekt C++ for OpenCL. Ten zajišťuje kompatibilitu, ale dělá to mimo samotnou vrstvu OpenCL. Použije se překlad kódu kompilátorem Clang/LLVM do formátu SPIR-V, který pak bude předán samotné implementaci OpenCL, s kterou již SPIR-V bude na rozdíl od C++ kompatibilní.
Galerie: prezentace záměrů, funkcí a novinek OpenCL 3.0 (Khronos Group, via AnandTech)
V budoucnu se opět rozjede i evoluce základní báze
Tímto restartem evoluce OpenCL by se snad mělo podařit tento ekosystém dát do pořádku a znovu také rozjet další vývoj, aniž by se zase dostal do slepé uličky. Do budoucna počítá OpenCL s vydáváním pravidelných aktualizací, které by přinášely různé opravy a „údržbu“, přičemž přidávání novinek má být opatrné a vyhýbat se předchozím problémům. To znamená, že novinky budou opět přicházet hlavně jako volitelná rozšíření.
Ovšem do budoucna se nepočítá s tím, že by báze zůstala zmrazená na úrovni OpenCL 1.2 věčně a nic do ní nikdy nepřibylo. V budoucnu budou přidány i nové funkce povinné pro všechny, které opět povinné nároky zvednou. Ale má to probíhat tak, že standardizovány jako povinné budou jenom takové funkce, které se již předtím osvědčily a odladily ve formě volitelných rozšíření. A které třeba již většina implementátorů stejně podporuje a je na nich konsenzus, čili je záruka či příslib, že po standardizaci budou skutečně přijaty a že místo toho výrobci hardwaru nezůstanou na starší verzi.
Zda se podaří tímto krokem OpenCL znovu nastartovat, teprve uvidíme. V tiskové zprávě se k nové verzi hlásí například Intel, Nvidia a Imagination Technologies, ale není v ní zmínka o AMD, které tedy možná buď nemá v plánu se s podporou připojit, nebo zatím vyčkává. Neznámá je také pozice ARMu, v případě Apple se počítá s tím, že na platformách iOS a macOS podporu nezajistí a bude tlačit vlastní proprietární API Metal.
Zdroje: AnandTech, Khronos Group
