A Khronos Group pár napja mutatta be a végleges OpenCL 2.2, SPIR-V 1.2 és SYCL 2.2 felületet, amelyekről be is számoltunk, ugyanakkor a konzorcium már azt is vizsgálja, hogy az OpenCL API merre fejlődjön tovább. Ez ugyanis eléggé fontos kérdéssé vált az utóbbi időben, hiszen valamerre el kellene indulni, de kulcskérdés a stratégia is, ami a terjesztés érdekében lényeges.
A Khronos Group az idei IWOCL rendezvényen felvázolta, hogy vannak terveik, elsődlegesen arra vonatkozóan, hogy a következő generációs OpenCL milyen legyen. Az tehát tiszta sor, hogy nagyjából mire lenne szükség, és az is, hogy a meghatározott igények jelentős részét a Vulkan API már kielégíti. Két dolog hiányzik az elsődlegesen grafikus feldolgozásra tervezett szabványból, mégpedig az OpenCL 2-es szintet elérő compute képességek, illetve a különféle processzortípusok támogatása, gondolva itt a DSP-kre és az FPGA-kra.
[+]
A legfőbb tervezet az OpenCL-V, amely lényegében az OpenCL és a Vulkan API-k egymáshoz történő felzárkóztatását jelentené. Itt arról lenne szó, hogy az OpenCL-re vonatkozó terveket időnként a Vulkan API-hoz és futtatási környezethez illesztenék. Ezzel a lépéssel a Vulkan idővel megkapná a teljes értékű SPIR-V támogatást, és nem csak az úgynevezett grafikai verziót, illetve beépítésre kerülne a legkülönfélébb típusú feldolgozók támogatása is. Itt óhatatlanul is opcionálissá kell tenni bizonyos funkciókat, elvégre egy DSP vagy egy FPGA a grafikai résszel nem sokra megy, tehát magát az alapvető API-t is több részre kell bontani.
[+]
Az előnyök azonban jelentősek lehetnek, mivel az OpenCL-V a fenti formában egy olyan egységes compute és grafikai környezet lenne, ami letisztult fejlődést biztosítana a teljes iparág számára.
A Khronos Group egyelőre a visszajelzéseket várja, de maga az OpenCL-V nem lenne annyira nehezen kivitelezhető, hiszen a Vulkan API alapjai adottak és nagyon jól működnek. A SPIR-V is kész van, csak jelenleg még szegmentált, de leginkább egy döntés kérdése, hogy a compute és a grafikai specifikációt végül összevonják. Technikai akadálya tehát ennek nincsen, csak az iparág most még nem igényli. Egyedül az esetleges OpenCL-V úgynevezett feature set specifikációit kellene meghatározni, ami nehéznek nem nehéz, de a gyártók bevonását igényli, tehát időigényes lesz. Emiatt az OpenCL-V nagyon a jövő zenéje még.
