Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: OpenCL Vulkan interop: how to do it?

  1. #1
    Junior Member
    Join Date
    Dec 2018
    Posts
    7

    OpenCL Vulkan interop: how to do it?

    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.

    Best regards,

    Erik

  2. #2
    Senior Member
    Join Date
    Mar 2016
    Location
    vulkan.hys.cz
    Posts
    358
    Hmm, seems to me OpenCL was left behind?
    I think you need to use DX or OGL as a middleman for Vulkan interop.

  3. #3
    Junior Member
    Join Date
    Dec 2018
    Posts
    7
    Is there any example around about what you are suggesting?

  4. #4
    Senior Member
    Join Date
    Mar 2016
    Location
    vulkan.hys.cz
    Posts
    358
    Well,
    Vulkan->OpenGL import is shown here: https://stackoverflow.com/questions/...gl-from-vulkan, resp. in therin linked code: https://github.com/jherico/Vulkan/bl.../glinterop.cpp.

    OpenGL->OpenCL import is shown e.g.: https://software.intel.com/en-us/art...ility-tutorial.

    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.
    Last edited by krOoze; 12-31-2018 at 04:46 AM.

  5. #5
    Junior Member
    Join Date
    Dec 2018
    Posts
    7
    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.

  6. #6
    Quote Originally Posted by ezorzin View Post
    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?
    And what happens if, in the near future, the sun explodes? Or a massive nuclear war breaks out? Because those have about the same likelihood as what you suggest.

    OpenGL support is not going to be dropped by anyone (other than MacOS, where the writing has been on the wall for years) in the forseeable future.

  7. #7
    Senior Member
    Join Date
    Mar 2016
    Location
    vulkan.hys.cz
    Posts
    358
    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.

  8. #8
    Junior Member
    Join Date
    Dec 2018
    Posts
    7
    I got your point

    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.
    Last edited by ezorzin; 12-31-2018 at 08:39 AM.

  9. #9
    Quote Originally Posted by ezorzin View Post
    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.
    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.

  10. #10
    Junior Member
    Join Date
    Dec 2018
    Posts
    7
    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:

    https://www.lunarg.com/faqs/vulkan-o...eroperability/

    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 - ?

    What is your opinion about this?

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean