I use OpenCL for developing physics simulation of soft materials. In my applications I open the graphics context by means of the GLFW and GLEW libraries using the so called “interop” modality, because I do all my computation by means of OpenCL kernels on a GPU (Nvidia) and I share to OpenGL the results via a buffer allocated on the GPU in order to have it rendered in real time by means of GLSL shaders. I do this on both mac and linux, I use gcc + cmake.
Recently I got interested in the Vulkan framework because, as far as I can understand, in the future GPU’s manufacturer will provide graphics drivers only for Vulkan, and the integration of various existing programming languages will occur only via SPIR-V compiled binaries.
I understood SPIR-V can compile OpenCL and/or OpenGL and therefore I understood I could load these compiled binaries on a sort of pipeline in Vulkan to be executed.
What I don’t understand is how I can implement, in Vulkan, the OpenCL-OpenGL interoperability mechanisms in order to have data shared from an OpenCL buffer to an OpenGL (or whatever else) rendering buffer within the client GPU without passing back and forth through the host device, therefore avoiding unnecessary slow bottlenecks in memory transfer.
In case this would not be possible, I would like to know whether there are other alternatives to implement computation+rendering in similar way I am now doing with OpenCL/GL interop. Possibly, I would like to keep my already developed OpenCL kernels, also because I do extensive use of kernels executed in a synchronised pipeline: e.g. sometimes I need one kernel to wait the results of the previous one before continuing the simulation. As far as I can understand, computation performed inside Vulkan shaders does not offer much synchronisation “outside” the shaders, but only “within” shaders in a fashion similar to the “barriers” mechanism in OpenCL.
I could not find any official Khronos statement, nor instructions, about any sort of such “buffer sharing” or “interop” between OpenCL and OpenGL in Vulkan.
Any clarification on this topic would be greatly appreciated.
My hope is it should just be possible to chain the two. Then again pointless, as you would be using OGL anyway. And if you are just using OGL to display precomputed data, don’t expect all that much benefit from Vulkan. There’s no harm in using OpenGL for simple stuff for the forseeable future.
Might indeed be simpler to port it to Vulkan. clspv should be able to produce Vulkan Compute Shader from a OpenCL C Shader, with minimal changes. Assuming you are not doing something smart in OpenCL API, rest should be only replacing OpenCL dispatch with Vulkan equivalents, e.g. vkCmdDispatch.
Vulkan can import\export (assuming caps are met) a Win32 NT handle. Unless I missed something I can’t find appropriate OpenCL extension that would accept that handle (unlike OpenGL). Might be worth raising this at KhronosGroup/Vulkan-Ecosystem.
In fact, I would be happy not doing anything on my happily working code! My point is: what happens if in the near future Nvidia, or others, will not provide anymore a graphic card supporting an OpenGL driver, in favour of Vulkan? In the latter case I will have to rewrite all my code in what-so-ever standard compatible with Vulkan…
…the time passes, and I have the feeling manufactures always find new ways to force developers re-doing the same things they were doing, but in new cumbersome ways…
(my apologies for the last comment of mine, in case I offended any manufacturer!).
Am I safe in continuing developing OpenCL code + OpenGL interop for real-time rendering, or should I switch to some other paradigm before it’s too late?
Apple already deprecated OpenGL and OpenCL (…and they created it…) in favour of Metal: not even Vulkan, which I was anyway able to run on my mac thanks to the MoltenVG intermediate driver.
Apple is somewhat specific. They can jump of a cliff and US consumer would follow enthusiastically.
Nobody is ever safe. Then again the reverse may happen, e.g. MS deciding to actively sabotage Vulkan. Just pack a towel, and don’t panic.
In this case, for the purpose of my OpenCL/GL applications, at the moment I would be not interested in further understanding how to implement an alternative interoperability mechanism besides the one I am already using if I could find an official statement of any long-term support, as you are suggesting.
Sorry for insisting with this question, but the reason for which I am asking it here is because I read about such hypothetical drops of OpenCL/GL + interop in other forums.
I got confused about these future plans, and therefore I am looking for some clarifications. I believe your solid likelihood estimation is based on the information written in some existing document I could not find yet.
Do not take what I said as some kind of “official statement.” At the same time, you should not take “official statements” as being of any worth. Make decisions based on what you see happening in the industry, not based on what companies try to tell you they will do.
No “official statement” of support was needed to see that Apple was abandoning OpenGL support. They stopped upgrading their iOS OpenGL ES and MacOS OpenGL versions. They created a new graphics API and pushed it as a replacement for OpenGL. The eventual deprecation of OpenGL was not some sudden revelation; it’s merely telling us exactly when they intend to do the thing we already know they’re doing.
My estimation is not based on “some existing document”; it’s based on seeing what’s happening and what isn’t happening. Does NVIDIA support OpenCL? Not really; they haven’t been keeping up with OpenCL versions and they have a competing standard. You don’t need an “official statement” to know that they don’t really care about OpenCL all that much.
Has any IHV dropped OpenGL support? No. Has any IHV slowed down their OpenGL support? Not outside of their previous pace of support (NVIDIA has always tended to provide support for new versions quickly, AMD has always been slower, and Intel has always been “whenever we get around to it.”).
Do not rely on “official statements,” even if they exist. Look around at what people are doing and remain flexible to changes. That’s the most effective way to keep moving forward.
According to this vision, since my question is about the availability of a an OpenCL/GL interop in the present/future or any alternative similar mechanism implemented in Vulkan, shouldn’t we conclude that OpenCL is dying, at least from the Nvidia side? I can easily explain the fact Nvidia seems not to support OpenCL because they have a proprietary alternative which is Cuda: if Cuda is better supported than OpenCL then a customer might decide to buy a Nvidia card instead of one from a competitor. It’s a marketing strategy.
At the same time, also Khronos seems not providing enough information about the topic of my question: not a single complete example of interop between OpenCL and OpenGL in Vulkan.
I can also understand anybody who can afford to pay the 75k$ fee for the subscription to become a promoter member of Khronos can have an influence in determining what will be the future development of a standard. All major manufacturer are in that group. But I am fine with this, it’s perfectly legal.
When I am asking for an official declaration I speak about something like this:
However that is just the very short reply to a simple question, which in fact exactly reflects the core of my question here.
They give no full answer to that question: it does not give any detailed information. But because they say they have made a “…strategic roadmap direction decision…” I got interested in understanding if such kind of decisions are somehow undisclosed in a way we developers have public access to, or for some reasons they are secret and we can only speculate around them.
In the end, at the moment, I can’t find either an example of what I am asking for, nor a statement of support (or drop of support) in favour of it. While other features of Vulkan are fully advertised everywhere. You see why I have doubts about this issue regarding the interop? I understand what you say about looking around at what people are doing, however I would like to have more control on my projects, since they depends also on those decisions and I am open to other options too. For instance, if I pay the fee for an academic subscription, would I have access to such information I am looking for? Or there is no way to know it, simply because nobody knows what I am asking for - for the simple reason the information I am looking for does not exist - ?
Um, yes. That’s been reality basically since NVIDIA stopped updating their OpenCL versions.
I assume there’s a typo or something in there, since “interop between OpenCL and OpenGL in Vulkan” makes no sense. I mean sure, you can probably chain OpenCL/OpenGL interop with OpenGL/Vulkan interop, but it’s unlikely that there are enough people who want to do that that you’re going to find examples. Furthermore, that’s not something that Khronos would want to endorse because… well, it’s prima facie silly.
[QUOTE=ezorzin;44096]When I am asking for an official declaration I speak about something like this:
However that is just the very short reply to a simple question, which in fact exactly reflects the core of my question here.
They give no full answer to that question: it does not give any detailed information. But because they say they have made a “…strategic roadmap direction decision…” I got interested in understanding if such kind of decisions are somehow undisclosed in a way we developers have public access to, or for some reasons they are secret and we can only speculate around them.[/quote]
Nobody is confused about what you’re asking for. But the fact of the matter is, they’re not going to give people those details until they’re ready to give people those details. And even then, until actual extensions/Vulkan versions/implementations come out, any such details are mere words, worth only the medium they’re printed on.
As an example, there were lots of “official statements” in 2006-7 about a revamped OpenGL API. Indeed, they were incredibly detailed, including example code of what the revamped “Longs Peak” OpenGL API would look like.
Nothing came of that (or at least, what came of it was very much not what was promised). Words are meaningless without action.
That’s because those “features of Vulkan” are actual features of Vulkan. They’re not ideas or plans or “statements of support”; they’re stuff you can do right now.
You should have doubts about it. Indeed, the statement you cite is not about interop; it’s about merger. It’s essentially saying that the intent going forward is for Vulkan to adopt the things that OpenCL can do which Vulkan cannot.
And again, since nothing has actually moved beyond the planning stage, you should not tether your current production to something that might not ever actually happen.
Basically, don’t plan on it happening.
[QUOTE=ezorzin;44096]I understand what you say about looking around at what people are doing, however I would like to have more control on my projects, since they depends also on those decisions and I am open to other options too. For instance, if I pay the fee for an academic subscription, would I have access to such information I am looking for? Or there is no way to know it, simply because nobody knows what I am asking for - for the simple reason the information I am looking for does not exist - ?
What is your opinion about this?[/QUOTE]
Well, you seem to have two choices. Choice #1 is to pay some money and hope that this gives you greater access to the Khronos Group’s progress and process. Though you’ll undoubtedly have to sign an NDA over anything you learn. How much money it will take to get access to what you want to know is beyond my knowledge.
But you also need to recognize that some things are not in Khronos’s control. All Khronos does is publish and support standards. They do not implement them. They cannot force NVIDIA to implement OpenCL. Even if they try to merge OpenCL with Vulkan in some way, they cannot force NVIDIA to implement that merger (which will almost certainly be an extension or optional Vulkan 1.2 feature, which NVIDIA would be free to not implement as they see fit).
So even if Khronos plans to do something, that guarantees nothing about whether it will be of practical benefit to you. You have to look farther than that.
Choice #2 is to stop worrying about what will happen beyond 3-5 years. Ask yourself these questions, given everything you know as it currently stands:
1: Will OpenGL still be available and usable on the platforms I’m interested in supporting, in 3-5 years?
2: Will OpenCL still be available and usable on platforms I’m interested in supporting, in 3-5 years?
3: Is OpenGL/OpenCL interop acceptable for my current project(s)?
If the answer to all of these questions is “yes”, then you should move forward with what you have, and let the future sort itself out in due time. For question 1, the answer will be “yes” for any non-MacOS platform, but you already knew that. For question 2, the answer will be “yes” for any non-NVIDIA, non-MacOS platform.
I see what you mean, we could summarise it with the socratic sentence: “we know that we do not know”.
Considering what you are suggesting and since neither the GPU manufacturers or Khronos discloses their future plans (and even in case they do it officially they have no practical 100% validity), my logical conclusion is that if I want to be al least a little bit safer than I am now in developing some code on my current framework - I am now speaking of the OpenCL/GL interop - I would be better moving my physics simulation computation inside an OpenGL shader, compile it with SPIR-V and plotting the graphics output through Vulkan.
Since the latter toolchain already exists, it is documented, and also looks to be supported by various manufactures (Nvidia too), I would say all this sounds more promising than “hoping” somebody will continue supporting my current framework.
In choosing this, I would pay the cost of porting my code “now” on a different framework but I would get the advantage of a longer estimated future maintainability.
On the contrary, if I don’t do this now, later it could be more difficult for me to port my code: the “zero-effort” solution of not doing anything, leaving my code as it is, and waiting for an integration of the OpenCL interop in Vulkan (as suggested by the link i reported from Lunar-G), despite being optimal to me, seems to me to have lower chances.
And doing everything in Linux, since I don’t want to jump the down the cliff with my lovely mac