No Vulkan OpenCL interop?

[krOoze]

Per discussion in https://forums.khronos.org/showthread.php/13965-OpenCL-Vulkan-interop-how-to-do-it I cannot find direct interop from OpenCL to Vulkan. Unless I missed something, OCL seems to only accept OpenGL and DirectX handles.

Should an extension be released to allow this interop path too (at minimum to help gradual porting)?

[neiltrevett]

A lot of discussion on the forum around this and related topics - let me try to provide some updates/insights that are hopefully useful:

• the OpenCL Working Group is about to start work on an Vulkan/OpenCL interop extension - the initial proposal is being generated by NVIDIA. We don't have a committed timeline yet- but its good to see the interest here - we will update as soon as can

• the GPU vendors are not going to stop shipping OpenGL drivers. I personally would not be surprised if OpenGL is around for another 25 years - it is used so extensively throughout the industry. The OpenGL working group is active - and able to develop new functionality if there is market demand - let us know your thoughts!

• Khronos indeed has no control over what APIs platform vendors choose to ship. That's why Khronos and many Khronos members are investing in open source tools for "Deployment Flexibility". E.g. the clspv compiler project is working to enable developers using OpenCL to deploy on a Vulkan run-time, the Vulkan Portability project is working the enable Vulkan code to be deployed over DX12 and Metal (and yes - we are thinking about OpenCL over Vulkan over Metal - it should work - but early days).

• the OpenCL roadmap is being very actively developed. As publicly outlined at IWOCL - the plan for OpenCL Next is to enable significantly more deployment flexibility of OpenCL itself. Not all platforms need all the functionality of 2.X - OpenCL Next will enable vertical markets to deploy/use the relevant OpenCL functionality more effectively and widely.

• Khronos has talked about the convergence between OpenCL and Vulkan - a little clumsily as it turns out - as the message has been often misunderstood - our bad. To clarify:
  a. OpenCL is not going away or being absorbed into Vulkan - OpenCL Next development is active
  b. In parallel with a. - it is good for developer choice if Vulkan also grows its compute capabilities
  c. OpenCL can help b. through projects like clspv that test and push the bounds of what OpenCL kernels can be run effectively over a Vulkan run-time - and maybe inspire Vulkan compute capabilities to be expanded.

This is where there is understandable potential confusion - if Vulkan compute capabilities expand to increasingly match OpenCL - why do we need both APIs? There are many reasons - the most obvious is that Vulkan is a GPU API, whereas OpenCL enables programming of heterogeneous compute resources. Vulkan is unlikely to ever be available on systems without a GPU. But even when 'just' programming GPUs, a compute API can bring a different perspective than an API that is also tasked do efficient graphics. Again - developer choice is good.

Lastly - no-one needs to become a Khronos member to influence API evolution - we do our best to listen to developer requests and pain points here on GitHub and on the Khronos forums - keep the feedback coming - good and bad!

[krOoze]

Thanks!

Vulkan is unlikely to ever be available on systems without a GPU.

Well, it's not that outlandish. Vulkan by design allows headless, and compute-only.

[Zingam]

Aren't we at the point where graphics, AI, etc. APIs should be developed as a part of the compute pipeline and not the other way around? After all everything is a form of a computation?

[krOoze]

@Zingam Specific API is more performant than general. You would have to find a way to expose the stages of Graphics pipeline as compute, while promising some benefit from doing so to offset the added complexity. If anything the new RT pipeline is better target to merge with compute pipeline (compute can too benefit from having intersection intrinsics, as well as better memory access, which seems to be what the HW behind it is actually doing to accellerate it).

[Cazadorro]

@Zingam GPUs still have asics that handle hardware rasterization that can't be modified directly via compute programs, but in something like opencl it would be quite cumbersome to insert graphics into the compute API. We see all the special stuff like pipeline and renderpass information in vulkan, its quite a lot of extra API surface area completely not needed in a compute API. However I already see Vulkan as a combination of OpenGL and OpenCL, a lot of the synchronization concepts are very similar.

Ignoring physical addressing, (which isn't important for many applications), the biggest thing in OpenCL we are "missing" in vulkan is a usable and scalable language with adequate generic programming given the restrictions of a GPU, with the ability to include other libraries. OpenCL has this with its OpenCL C++ language. With vulkan we are still stuck mostly with GLSL and HLSL both which are woefully inadequate for large scale graphics applications, let alone compute. ShaderC alleviates some of these issues, but as of yet nothing challenges OpenCL C++ language or the CUDA C++ language. But because of SPIR-V it isn't necessary for Khronos group to work on this nor is it necessary for OpenCL to be merged with Vulkan for a better language to be provided.

[Degerz]

Honestly, I wouldn't even bother with OpenCL at all anymore since it's a dead end compute API and if Khronos Group's record is anything to go by then their OpenCL successor is as good as dead on arrival. It took years for the standard to adopt a comparable modern programming model to that of the highest end solution yet no vendor implementation supports it ...

It reveals a whole lot about a standardizing body which create new APIs and is then fascinated to create translation layers around them, doesn't it ? Being haphazard was popular with Khronos back then but I guess the new fashionable thing is planned obsolescence, at least that's what I perceive it to be. It's extremely disappointing how we're now left with a disaster of a compute API because of how Khronos lacked so much foresight in accepting a reactionary proposal from it's former member and overseeing the standard's development (or lack thereof I should say) over the past years ...

If the issue opener is only considering OpenCL for experimentation purposes and doesn't care about the implementation quality or future support then there's not much room for objection for that use case but for anyone else serious about shipping support in their applications then my only recommendation is consider every other option out there even if they are proprietary solutions since application authors don't have to deal with the tyranny of a poorly maintain platform that is OpenCL ...

It's a tragedy that a future can't be envisioned where a single and open compute API dominates. There's currently 4 compute APIs out there and counting so far not including the replacement by Khronos or a solution recently announced from another hardware vendor. The working group is overestimating demand for an OpenCL successor ...

[ezorzin]

Hi, I am the person who opened the issue here introduced by krOoze. First of all, thank you to everybody present in this discussion. I am not using OpenCL just for experimenting with the code but for scientific research purposes. By saying this what I want to say is that, besides being programming for many years, I am more interested in the application in my field and therefore I still consider myself far from being an expert in OpenCL. My confusion comes from this picture: it is therefore difficult to me to understand what is the most convenient strategy to try to develop a long-term project based on GPU computation/simulation. Without repeating myself (the discussion can be followed here: https://forums.khronos.org/showthread.php/13965-OpenCL-Vulkan-interop-how-to-do-it) but even staying within this thread I see examples of apparently contradicting point of views:

1. citing neiltrevett: "the OpenCL roadmap is being very actively developed. As publicly outlined at IWOCL - the plan for OpenCL Next is to enable significantly more deployment flexibility of OpenCL itself."
2. citing Degerz: "Honestly, I wouldn't even bother with OpenCL at all anymore since it's a dead end compute API and if Khronos Group's record is anything to go by then their OpenCL successor is as good as dead on arrival."

I respect both of them, however I believe this example clearly shows how difficult is, for a non-expert like me, to formulate a solid opinion when reading such different statements :)

I can accept to rewrite my already developed code in whatever else computing/graphics framework, if what I am using now is dying, because I need it for my work. But is OpenCL (particularly the interop capability) really dying? That was the core of my original question.

[Degerz]

@ezorzin It all rests upon what your project goals are to see if you feel whether or not OpenCL is appropriate for your use case so here's an outline below concerning the circumstances regarding OpenCL ...

1. If you want your projects to be portable as much as possible then you can only target OpenCL 1.2 certified devices because the one big hardware vendor with lot's of lobbying power may never ship OpenCL 2.x capable drivers so this greatly limits your capable feature set ...

2. Some vendors have stopped certifying their OpenCL implementations like AMD and Apple so this means that they as vendors do not make promises that your application will run properly in the future and in an extreme case may feel the need to deprecate it on their future platforms like Apple with macOS/iOS ...

If you have no qualms about dealing with OpenCL maintenance issues with big projects and you still need graphics capabilities it might be necessary to put out an extension or allow SPIR-V kernels in Vulkan. One would have to be in a very critical position to require OpenCL's ill conceived programming model ... (but if you badly need graphics and compute interop then I suggest that you consider using OpenGL instead of Vulkan)

If you are only thinking about doing compute then I'd consider the other solutions first like Nvidia CUDA or AMD HIP since they have a single source C++ programming model is which by all accounts very powerful and is far less verbose compared to OpenCL. Depending on Intel's developing compute API solution, if they go the route of single source C++ as well then OpenCL as a compute API is undeniably dead at that point and whatever Khronos had in mind is dead on arrival as well. Currently, the 3 hardware/platform vendors and the deep learning community have very good reasons to shun OpenCL ...

[bhack]

There are also some fresh interesting plans for Sycl in Clang/LLVM https://www.phoronix.com/scan.php?page=news_item&px=Intel-SYCL-For-LLVM-Clang

[ezorzin]

@Degerz Could you please elaborate this observation of yours: "...OpenCL as a compute API is undeniably dead at that point and whatever Khronos had in mind is dead on arrival as well..."?

In order to give you an idea of the kind of stuff I work on, let's consider a simple practical example of physics simulation: I have a 2D cloth, in a 3D world, made of millions of particles interconnected by springs. The simulation takes real mechanical parameters and seeks for a physical exact solution, not just a "good looking rendering", and goes like this:

1. for each particle I compute the forces of the first near neighbours: I do this in a single OpenCL kernel, spreading the computation in parallel on all available compute units. This way this computation is done in a single shot on all particles (since there are so many compute units in modern GPUs).
2. In a predictor-corrector integration strategy, once the first step is finished, a second one (the "corrector") performs another similar computation: this is done by a second kernel, synchronised in order to wait the first one to be completed before the second one can run, again doing computation on all particles in one shot.
3. Since all the results of the calculations (particles' positions, velocities, etc...) are now already on the GPU memory as OpenCL buffers, I take advantage of the interop to 3D render the cloth by means of OpenGL shaders. I do this continuously, in real time: this way my cloth is simulated and displayed without unnecessary delays due to unwanted memory transfers between host and client. Data are computed and rendered directly by the GPU, on its own memory. This makes the simulation very fast.
4. The updated memory buffers (positions, velocities, etc...) now serve a starting point from the successive computation, continuing the simulation for the next time step starting back from point 1 of this description. This continue forever in a loop: as the time passes, the 2D cloth simulation evolves.

Whatever underlying parallel-hardware cannot escape this 2-step looped computation when using a predictor-corrector integration mechanism (here I am skipping all the technical details of the mathematical advantage of this method).

Here the interop capability is crucial: otherwise I would waste a lot of time if I could not 3D render the data (e.g. particles' positions) already present in the GPU memory. Also I would waste a lot of time to pass the results of the first kernel to the second, or from the second to the first for the next time step computation. Not being able to do this would mean copying huge data arrays back and forth between client (GPU) and host (PC) memory. That would make the simulation becoming very slow, at the point that a single CPU in a PC is faster: this way I loose all the advantages of a parallel GPU computation.

Here, in this example, I am not working with pre-computed stuff to be rendered, nor with fancy graphics effects: I am just 3D plotting millions of points in real time, as they are continuously generated by the computation the way I described above.

Besides the underlying math and physics, giving this example, is there any alternative to the OpenCL/GL interop paradigm in order to achieve the same functionality?

One alternative I can see is CUDA/OpenGL interop, but I don't know it for sure since at the moment I do not program in CUDA yet. Do you know others? As far as I have understood, SPIR-V can compile OpenCL kernels, but I couldn't find a way of assigning the pointers of the corresponding client memory buffer to any rendering "kernel" in Vulkan without passing the data back to the host via Vulkan: if that is possible I would call it "interop".

I don't understand what other things besides my current OpenCL/GL paradigm can do more for me, considering the type of applications I have. Why, within this example, Vulkan should be better?

[Degerz]

@ezorzin My observation is based on the fact that OpenCL has thoroughly failed to become the leading industry standard for compute APIs and that there's no demand for it either in many application projects but Khronos stubbornly refuses to come to terms with the reality.

You have to be a little bit more specific on what your requirements are exactly. Are graphics APIs like OpenGL or Vulkan that have fixed function acceleration absolutely necessary for you to render the graphics in your simulation ? Is it an option that you could create a software rasterizer in OpenCL and then render the graphics ? More specifically, have you looked into refactoring your simulation to use OpenGL or Vulkan compute shaders instead of OpenCL kernels ?

When it comes to graphics and compute interop you have a very limited set of options out there such as OpenGL/OpenCL or OpenGL/CUDA and there's only one API that attempt to unify both which is the Metal API but that is only available on Apple platforms. Vulkan by design has a shader execution model rather than a kernel execution model like that of OpenCL so you're basically forced to pick one or the other if you want more options because currently, Vulkan to my knowledge does allow the usage of SPIR-V kernels.

Your current approach seems fine for the most part so I'd be hard pressed to see a benefit as to why you would need interop with Vulkan or Vulkan at all since it's just another graphics API. Are you interested in any of the features that are specific to Vulkan that would warrant an OpenCL interop extension at all ? CUDA/OpenGL interop might actually end up being better than a possible OpenCL/Vulkan interop in your case if you end up not needing any Vulkan specific features just by the virtue of it being a better supported platform and is easier to maintain.

[pdaniell-nv]

@ezorzin I'm curious. What version of OpenGL are you using and are you using any compute features in OpenCL that aren't already in OpenGL?

[ezorzin]

At the moment, on my the laptop where I develop most of my code (MacBook Air), I have the last available frameworks from Apple: OpenCL 1.2 and OpenGL 4.1. I have other two Linux machines and now I am going to build a dedicated computer only for simulation purposes.

Using OpenGL as compute shaders is actually the option I am evaluating with my greatest interest. At the moment I am stuck to OpenCL for historical reasons: I started long ago working with that framework but now I am facing the problem of understanding if it makes sense to stay in that framework or to change it in favour of a better one. I understand some people might be puzzled for the reason there are some others, like me, who would like not to change their compute paradigm in favour of new things: the reason is that when working for long time projects (e.g. scientific research) it is difficult to dedicate resources for redoing something that has been already done just because the standard changes. This is the same reason for which, for instance, you still find people programming in Fortran in the physics sector: just because they have tons of libraries that work fine and they can't afford having people doing a porting in a more modern language.

I don't need other features besides what I tried to explain in the previously described example.
Basically I need a way of running "kernels" (...or whatever name you like to give to some executables running on a parallel compute hardware) in a way that I can synchronise their execution (= waiting for one "kernel" to be done before another can start) and a way of accessing that memory for a direct rendering. I would be fine with whatever framework allow me to do so.

The point is understanding how far can I go keeping what I already have before it's too late for changing (in case OpenCL will die): it doesn't look to me that Vulkan is offering something significantly different that what I have now. It seems to me Vulkan is there mainly only because of marketing reasons, more than new functionalities. I can understand the idea of something naturally dying because something else new and better has come: but it's difficult for me to accept investing my time in translating my code into another language just because some manufacturer is, indirectly but deliberately, pushing programmers to continuously re-write their code just because they have to sell their products. I stop here because I believe this is not the place for a polemic discussion.

Of course I will do it, in case there are no other alternatives: at the moment I found about 50% of people saying OpenCL in fine, and another 50% saying it's dead.

At the moment I am refactoring my code in a way I created a sort of high level language based on low level functions that I can more easily change in case I have to do a "handover" between a new compute/rendering framework without having to re-write my code entirely.

[ezorzin]

P.S: another reason I'd like to keep OpenCL, if possible, is also because I was planning to run some of my code into an FPGA: it would be so good if there would be any VHDL open core implementing a GPU, but we are very far from this in the FPGA field. For this, OpenGL (or Vulkan) can't be used in FPGA nowadays.

[krOoze]

Seems we contracted bad habits from gaming community, saying this or that is ded.

Anyway, I opened this because there is obviously missing path OCL->Vulkan. It seemed bit awkward that such path exists from DX, but not from a sibling API... Irregardles of what is dead or not, it is good for APIs to be compatible this way.

We carried a lot of chatter here from the forum post. API choice is opinion-based. Personally I don't see why not continue your app with OpenCL. If the worst should happen, porting path shall present itself surely (maybe even OCL wrapper). And outright hardcore porting to Vulkan does not seem so difficult either, so not sure if it is rational to be worried about it years\decades in advance.

[Degerz]

@ezorzin Sometimes we need to deal with the fact that standards go out of favour and that includes OpenCL. Your requirements seem paradoxical as well since you want an API that runs on a FPGA, is capable of low latency compute/graphics and potentially a better supported platform too. Unfortunately, there may not exist such an API that meet your requirements. Both hardware/platform graphics vendors and FPGAs have interests that currently run counter to each other. For the former, they can't promise that they'll keep providing OpenCL drivers to your benefit and it's a very high likelihood that support could be effectively phased out in the next 5 years. FPGA manufacturers currently have no interest in adding graphics capabilities to their devices yet OpenCL on it's own is probably not appropriate in your case either ...

It's going to be a very difficult decision to make regarding what you want to use in the future. If you're more concerned about about technical debt rather than some off chance that FPGAs will provide graphics drivers then I would recommend that you immediately drop OpenCL altogether and only consider looking at either OpenGL or Vulkan compute shaders. That being said, the device you mainly develop does not support OpenGL compute shaders but if it does officially support macOS Mojave then your device is probably capable of Metal acceleration so consider using MoltenVK which is a translation layer between the Vulkan API and the Metal API. This approach will allow you to use Vulkan compute shaders on Metal with the biggest benefit being you can target a well supported and the most portable standard too in the future ...

Vulkan alone isn't better than your current OpenGL/OpenCL approach but it's definitely worth checking out since it'll probably add at least a good 2 decades worth of lifespan to your projects compared to the older APIs ...

[ianmbloom]

Hi @neiltrevett and others.
I'm curious if there is any news about OpenCL Vulkan interoperability as 2019 comes to a close. Very keen to have a clear picture of OpenCL's future as it's still being used in this engine https://github.com/ianmbloom/gudni
Thanks,
Ian Bloom

[neiltrevett]

Hi Ian - the OpenCL working group continues to work on the OpenCL / Vulkan interop extension - I know its been a while - but there have been productive working group discussions on how to make it as useful and usable as possible. I would expect to have public specifications in the next few months.

[ianmbloom]

Fantastic to hear! Thanks for the response.

[BrokenFlame]

Radeon are list Vulcan API Support, but no longer list OpenCL, and Nvidia are only ever seem to support OpenCL v1.2.

I need the massive parallelism of GPGPU processing on Windows, Linux and MacOS (yes MacOS). The application was previously writing in C with OpenCL. It is time for me to update/rewrite the application and I'm not sure which way to turn, as this the application will run until 2030 to complete the research. So I need something which will be supported by the hardware for at least the next 5 years, before needing updating (not rewriting).

I'm looking at OpenACC, and OpenCL. Is OpenCL still going to be an option for me? Speed is a real problem as the application is run all over the world on researchers laptops (not all that powerful) as the location can be very remote, so onsite processing is required.

[Degerz]

@BrokenFlame The reason why AMD doesn't list OpenCL support anymore is because they stopped submitting drivers/hardware for OpenCL conformance testing so there are no promises that your valid OpenCL application will run on newer AMD hardware like Vega or Navi. AMD obviously intends to stop supporting OpenCL altogether in the future so they've effectively halted development of their OpenCL driver implementation and is now in "maintenance mode" for the time being until it reaches deprecation in the future ...

As for Nvidia, they did not care about OpenCL from the start and were arguably one of the earlier opponents of the standard ...

If you absolutely must need to be able to support all platforms then Vulkan+MoltenVK is your only real option to attempt this with the least amount of possible maintenance. OpenCL will never become a viable option because of the politics behind from some of the Khronos members. Unlike the Vulkan standard, Khronos Group can not be trusted anymore to develop the OpenCL standard!

[marty-johnson59]

This repository is being archived as it has been replaced with the vulkan.org website and is no longer being maintained (i.e., issues posted here are no longer being addressed ). After reviewing issues posted here, most (if not all) have been resolved or have already been re-opened in Vulkan-Docs (https://github.com/KhronosGroup/Vulkan-Docs) or other repositories for further consideration. Therefore, all issues in this repository will be closed. If you believe your issue has not yet been resolved, please re-open in Vulkan-Docs. Thanks!