Vulkan and OpenCL

>> Sunday, March 8, 2015

I've read the slides (PDF) from the presentations on Vulkan, and I've learned a great deal. But two things puzzle me. First, it's clear that Vulkan is intended to replace OpenGL, but nothing I've read suggests that it may replace OpenCL. But how can a compute-only language stay relevant when a graphics-and-compute language is available?

One important distinction is that, unlike Vulkan, OpenCL runs on devices that aren't GPUs. Intel has an OpenCL SDK for their CPUs and Altera has an SDK for their FPGAs. I've read that Texas Instruments is working on an SDK for their digital signal processors (DSPs). Still, the OpenCL developer base is so small and the API is so complex that I wonder if it's worth the effort.

My second question involves Nvidia. They've spent many years and millions of dollars trying to convince people that CUDA is the language for GPU computation. What do they gain by supporting Vulkan? I'm sure Vulkan will never approach CUDA in features or performance on Nvidia hardware, but it still seems odd to hear their representatives praising a competing language.

5 comments:

Christian March 8, 2015 at 10:01 PM  

As far as I understood the whole thing, the key audience of Vulkan differs from the people using OpenCL. Vulkan points to the gaming industry and their graphical overload (vertices, meshes...). OpenCL is mainly used (in my eyes) for scientific and multimedia data handling.

I would place myself in the OpenCL user group. I do not want the additional graphics API, as it violates my idea of a slim computing API.

At least, as both languages merge in the SPIR-V layer, the vendors point of view is much more uncomplicated. They get the same code base from the intermediate layer to support.

I guess, the question seems like: why do we need JavaCL, PyCL,...? Because people from different OpenCL fields share the same ideas of numerical solutions and therefore the same API. That's the same reason why - at least for me - Vulkan and OpenCL have both a legitimation. That worked for OpenGL and OpenCL/CUDA in the past years too, so it will be the next 6-8 years (at this time, streaming processors will be only one to survive).

Matt Scarpino March 9, 2015 at 4:30 PM  

Judging from the GDC slides, the Vulkan and OpenCL APIs have a fair amount in common, including device objects, queues, commands, and memory objects. I'm not sure OpenCL is slimmer, but we'll see.

As Vulkan receives more attention, I think developers and corporations will focus on it to the exclusion of other languages. Eventually, the developer base for Vulkan will grow so much larger that corporations will stop supporting OpenCL. Some are doing that already.

Vincent March 18, 2015 at 7:27 AM  

One remark. I wouldn't label OpenCL as complex, just steep. In the base it's just a normal language with memory-operations and parallelism. Other parts (i.e. lots of code to even start), a lot of work has been done already. I'm not giving up on making OpenCL less steep, as long as OpenCL doesn't remove the explicit memory-operations.

Ádám István Szűcs April 3, 2015 at 4:40 AM  

Do you know if we would have device sided 'shader' execution in vulkan? It would be nice to get rid of that overhead :)

Matt Scarpino April 5, 2015 at 12:45 PM  

I can't say anything about Vulkan, but from reading the Mantle spec, it looks like an application can create multiple queues for a device. The device doesn't have any control over the commands, but it can process compute commands and graphics commands without the computer's intervention.

Post a Comment

  © Blogger template Werd by Ourblogtemplates.com 2009

Back to TOP