Thursday, May 18th 2017
Khronos Group to Merge OpenCL With Vulkan API
In a blog post detailing the release of OpenCL 2.2 with SPIR-V 1.2 integration today, Khronos put in an interesting tidbit, saying that "we are also working to converge with, and leverage, the Khronos Vulkan API - merging advanced graphics and compute into a single API." PC Perspective understandably found this worth further looking into, since as it is phrased, it seems as if OpenCL and Vulkan are going to be slowly developed towards parity (until eventually merging with it.)
Khrono's response to PC Perspective's inquiry was clear enough: "The OpenCL working group has taken the decision to converge its roadmap with Vulkan, and use Vulkan as the basis for the next generation of explicit compute APIs - this also provides the opportunity for the OpenCL roadmap to merge graphics and compute."Some interesting (and sensible) reasons for this integration stand in that it's much easier to develop a single API than two, so eventually all of Khrono's resources could be fed into Vulkan. At the same time, it is much easier to integrate some of the things that OpenCL now allows (such as FPGA and overall wider system support) into Vulkan, than the other way around. Integrating graphics tasks into OpenCL would be quantifiably more difficult and time-consuming than adapting Vulkan, which already has those graphics tasks, to OpenCL's strengths. Integrating both roadmap means that developers that are now using OpenCL can continue to do so, until the point comes where both APIs are so indistinguishable that they can make a painless transition towards Vulkan's more modern (and in some regards, more effective) features.
There are also licensing issues that have to be considered, since Apple, who originally created OpenCL, still owns trademarks and other rights to it, which means that Khronos has to license these when developing the API, which would no longer be necessary with Vulkan (based on AMD's contribution of Mantle, if you remember, for which the company charges no royalties.)
Al in all, this is an important "non-announcement" from Khronos' part, and could increase Vulkan's relevance in the market, not only as a graphics API, but as a general computing one.
Khrono's response to PC Perspective's inquiry was clear enough: "The OpenCL working group has taken the decision to converge its roadmap with Vulkan, and use Vulkan as the basis for the next generation of explicit compute APIs - this also provides the opportunity for the OpenCL roadmap to merge graphics and compute."Some interesting (and sensible) reasons for this integration stand in that it's much easier to develop a single API than two, so eventually all of Khrono's resources could be fed into Vulkan. At the same time, it is much easier to integrate some of the things that OpenCL now allows (such as FPGA and overall wider system support) into Vulkan, than the other way around. Integrating graphics tasks into OpenCL would be quantifiably more difficult and time-consuming than adapting Vulkan, which already has those graphics tasks, to OpenCL's strengths. Integrating both roadmap means that developers that are now using OpenCL can continue to do so, until the point comes where both APIs are so indistinguishable that they can make a painless transition towards Vulkan's more modern (and in some regards, more effective) features.
There are also licensing issues that have to be considered, since Apple, who originally created OpenCL, still owns trademarks and other rights to it, which means that Khronos has to license these when developing the API, which would no longer be necessary with Vulkan (based on AMD's contribution of Mantle, if you remember, for which the company charges no royalties.)
Al in all, this is an important "non-announcement" from Khronos' part, and could increase Vulkan's relevance in the market, not only as a graphics API, but as a general computing one.