
Vulkan and OpenCL will merge into a single API - mattiemass
http://hexus.net/tech/news/software/105895-vulkan-opencl-will-merge-single-api
======
roel_v
This is not true! The International Workshop on OpenCL was held this past week
in Toronto (OpenCL 2.2 was announced there), and there was a session with
several Khronos project leaders (including the chair). The future of OpenCL
was a big topic and they explicitly said that this has not been decided yet.
Yes, it probably makes sense to merge the Vulkan and OpenCL SPIR-V flavors
more, but that's not 'Vulkan anf OpenCL will merge'. If anyone reading this
was at the conference too and heard something different, please chime in - but
if what this article says was said there, it must have been in a parallel
conference with people saying the opposite things than what I heard.

~~~
roel_v
A bit more context after having re-read the OP: consider the following
diagrams:

    
    
        - https://www.khronos.org/assets/uploads/apis/2016-spir-10.jpg
        - https://streamhpc.com/wp-content/uploads/2015/05/khronos-SPIR-V-flowchart-550x323.png
    

The core thing to understand is that (a bit simplified) both Vulkan and OpenCL
(as of 2.2) run on SPIR-V IL. So in that context (with that common foundation
for both API's in the near future - well, depending on your definition of
'near' I guess...), it makes sense that someone at Khronos might have said
something about 'converging' \- large parts of the ecosystem can be shared
(compilers/transpilers, tools, ...), some parts of the API's might be
'aligned' more, ... But 'converging' is not 'OpenCL will be folded into the
Vulkan API', which I think is an overhasty conclusion by the author of OP. If
anything (at least, this was my impression from the conference), the big new
things for OpenCL are on devices that are not GPU's (well, on FPGA's, to be
more precise). This might require some specific support (for features) that
don't have a place in Vulkan at all. That's not saying that the alluded to
'aligning' or 'converging' can't happen, but there is no One API To Rule Them
All ('them' = graphics and compute).

So, to conclude: I see why the author would draw the conclusion he did, and if
what he cites really are literal citations then maybe the Khronos
communication could have been a bit more clear, but I don't think this
conclusion is correct.

~~~
ScottMichaud
Hello. I'm the author of the PC Perspective story that this post cites.

[https://www.pcper.com/reviews/General-Tech/Breaking-
OpenCL-M...](https://www.pcper.com/reviews/General-Tech/Breaking-OpenCL-
Merging-Roadmap-Vulkan)

I am currently writing up another post, which is based on an interview I did
with Tom Olson (Chairman of Vulkan) and Neil Trevett (President of Khronos
Group) on Friday. While the implications of the announcement are smaller than
I speculated (ex: the Khronos Group weren't concerned about Apple's ownership
over OpenCL's trademarks and a few necessary patents) the announcement is
correct.

Neil: "Congratulations. You win the prize for finding the extra press release
hidden in the quote."

I'm still digesting the dense, ~40 minute discussion, but OpenCL's roadmap is
to merge into Vulkan's. There's a bunch of reasons for it (ex: OpenCL pushes
FP32 support onto hardware where it doesn't make sense, like DSPs and deep-
learning applications) but I'll elaborate on that with the follow-up. Might
take a few days though.

Also, here's Neil's presentation from IWOCL:
[https://www.khronos.org/developers/library/2017-iwocl](https://www.khronos.org/developers/library/2017-iwocl)

~~~
roel_v
Thanks for following up here, and sorry that my reply is late - too late to
make any difference, probably.

Yes, I was at Neil's keynote that you link the slides for. I still do not
agree with your conclusions, or maybe rather with how you frame them. OpenCL
is not 'being merged into Vulkan'. Rather, 'the next version(s) of OpenCL will
align more ('converge') with Vulkan'. For example, you claim 'The Khronos
Group are converging OpenCL and Vulkan into a single API: Vulkan.'. I do not
get that from either of the Khronos 'clarifications', nor from any of the
presentations given last week, nor from any of the discussions I had with
people from the various Khronos workgroups, including the OpenCL-related ones.

I've asked a few other people who were there how they perceived the message
but haven't heard back yet. Maybe I'm just thick, wouldn't be the first time.
But for now I do feel that you're spinning a more sensational story ('OpenCL
will go away and be merged into Vulkan!' \- on a meta-level, it's a sad
reflection on my life that I consider that 'sensational'...) than what is
actually going on.

~~~
ScottMichaud
I'm still writing up the interview that I did with them (Tom Olson and Neil
Trevett) on Friday, after the initial post was published, but they do intend
to merge OpenCL into Vulkan.

One thing they did want me to make clear, though, is that this is an OpenCL
decision. Vulkan's roadmap isn't changing. While I'll elaborate in the follow-
up post, it's to move OpenCL more low-level and abstract (ex: as I said above,
FP32 makes no sense for many DSPs or deep-learning accelerators).

~~~
ScottMichaud
The interview is up:

[https://www.pcper.com/reviews/Graphics-Cards/Follow-Neil-
Tre...](https://www.pcper.com/reviews/Graphics-Cards/Follow-Neil-Trevett-and-
Tom-Olson-Khronos-Group-Discuss-OpenCL-and-Vulkan-Roa)

------
SoapSeller
Great, we may finally see good(as in performant) OpenCL support from Nvidia.

~~~
roel_v
OpenCL performance isn't the problem on NVidia, it's the lack of suppport for
OpenCL 2.x.

~~~
robert_foss
I would say that both parts are pretty bad.

NVidia has no interest in competing with its own propietary compute language,
CUDA.

------
protomyth
I wonder what the means for Apple and their desire for Metal over Vulkan?

~~~
mathnode
Metal has been out and working for two years. And working well.

Apple have a graphics API. Microsoft have a graphics API. Sony have a graphics
API. Nvidia have their own libraries and compilers and so do AMD.

~~~
zanny
And developers love rewriting their graphical backends for every target
platform, its the best!

~~~
bronxbomber92
In reality, for most developers, it is a non-issue to bringup a new graphics
API backend. See, for example, Arseny Kapoulkine's experience porting to
Metal: [http://zeuxcg.org/2016/12/01/metal-
retrospective](http://zeuxcg.org/2016/12/01/metal-retrospective)

~~~
ioquatix
One example is not most developers.

I'm a developer and I get paid to write hardware accelerated renderers and for
the past two years I've been recommending Vulkan.. I'm exclusively using Linux
these days for software development. Sometimes it's not about what you're
targeting for deployment but the capabilities of the development machine. For
example, I do like Xcode, but I can't use it for Vulkan development, even if
my ultimate platform isn't macOS/Apple.

Apple dropped the ball on Vulkan and I do hope they support it eventually.

~~~
pjmlp
Good luck using Vulkan on the PS, XBox or 93% of Android devices out there.

~~~
ioquatix
We develop server based hardware-accelerated renderers and compositors for web
applications, e.g. dynamically generated product images. None of those targets
are relevant. Think ImageMagick but done on hardware + 3D geometry in many
cases.

------
eriknstr
Great, maybe we'll finally get OpenCL support in the proprietary Nvidia driver
for FreeBSD? And then maybe CUDA support in their driver also? One can
hope/dream.

------
happycube
I figure there were good reasons why not to, but this really should've been
done for Vulcan 1.0.

~~~
Svenstaro
They had to get it out of the door at some point. The industry support they
received was tremendous as it was and I imagine more waiting would have made
some people there very nervous. I think it turned out well as it did.

