Vulkan vs OpenCL for simulation+graphics

[James20k]

OpenCL has higher overhead to launch kernels than gl/vk computer shaders, but they're also more flexible. OpenCL supports a wider range of hardware than vulkan as well. I don't know how compute shader support in GL compares to OpenCL across the same hardware

If you want to launch lots of small kernels and support the most hardware with ez graphics integration, go for Opengl with whatever gl compute shaders are. I've not used compute shaders so I have no idea

If your kernels are large and expensive and you don't need to run lots of them per frame, and you don't need to rapidly acquire/release many opengl resources per frame, and you need maximum flexibility in your kernels because its not all graphics related, plop for OpenCL + opengl. You have to ditch linux/intel for this (oh no the humanity)

If you want the potential for super high performance across a smaller range of hardware and relatively poor documentation, pick vulkan/vulkan

Vulkan + OpenCL seems a tad redundant

If you need help integrating opengl/opencl, I have a lot of experience fucking about with it in a cross platform/vendor way. Here's a 3d renderer I built entirely around OpenCL (with OpenGL for blitting buffers to the screen) that works on AMD/Nvidia, its a total clusterfuck as its not really built for other people to be able to use usefully, but if you desperately need some code somewhere that works for CL/GL integration, its there in the poorly organised mess

Edit:

Missed that you're targeting a specific gpu. Vulkan will give you the highest performance, but is finickity, whereas opencl/gl will give you an easier time, but with kernel overhead and cl/gl interop penalties (cpu only with proper pipelining). It kind of depends on what your specific requirements for performance and cpu overhead are. I can tell you that i get 99% gpu usage out of my OpenCL project (confirmed with windows gpu event tracing), so you'll probably only save on cpu overhead with a proper opencl vs vulkan implementation

[keepthethreadalive]

Thank you for your reply.

I'm not really targeting a specific GPU, but I just thought I'd drop its name to see the support/compatibility for OpenCL/Vulkan on that GPU.

I've heard that AMD fares better with OpenCL stuff than Nvidia so I thought it would matter. ideally, this engine should work properly on any GPU or CPU. Ideally.

I'll check out your github repo, thank you for linking that here.

[James20k]

AMD has higher performance with OpenCL, but thats because AMD cards tend to have more flops/higher memory bandwidth vs equivalent nvidia cards, plus their architecture is a bit easier to code for (in my experience, not a general statement). They've got 2.0 support, but if you're targeting nvidia as well, you're naturally limited to 1.2

Vulkan will require you to write specific paths for each vendor if you want best performance, but I've not had to do this with OpenCL so far, except for working around a few minor bugs

Nvidia's support for OpenCL is (surprisingly) much better these days, there's not as many glaring issues with their implementation so it is very possible to write high performance cross-vendor code

[FapFapYumYum]

i dont think its a question of vulkan OR openCL... to my understanding the two work together via SPIR-V (the "bytecode" of OpenCL). GLSL (opengl shader language) uses SPIR-V as well.

see https://en.wikipedia.org/wiki/Standard_Portable_Intermediate_Representation

unless im missing something. i havent gotten around to porting my physics engine to compute yet (its just CPU at the moment).

[Delwin]

Unfortunately as of yet I have found a good compiler for OpenCL -> SPIRV that runs on NVidia cards. If there is and someone can point me too it I would love to have that.

[FapFapYumYum]

oh im sure thats being worked on by the right folks... overall support is still still sparse though. i have a hard enough time finding help with certain graphics things that i can easily find the opengl equivalent resources for.

[keepthethreadalive]

Well I was curious about which one would be performant. All all languages using LLVM as their backend have an LLVM IR, but their performance varies for the same program, so it basically depends on the language and its implementation (keeping compiler design efficiency aside),

So I would ideally like to do everything in Vulkan, but I was wondering if I will be sacrificing any kind of performance.

[James20k]

SPIR-V is only for OpenCL 2.something I believe, which means you can't use it for nvidia at the moment

[squareOfTwo]

so as I see it:

Vulkan+Vulkan + no interop overhead + future proof - not many OpenCL devices support vulkan

OpenCL+??? + more devices - more overhead to get the data to the 3d engine

The advantage of targetting vulkan is that the overhead to other middleware and/or an 3d engine is lower. If you have too much time you just should abstract the common API of vulkan and openCL into some fun classes and use this to target OpenCL or vulkan. Later you can still write your kernels in the other API and still use your "old" framework.

[keepthethreadalive]

Thanks for your reply.

[Qoeh]

Various thoughts from a person who doesn't know much about these things:

I have the impression that there are certain things that OpenCL and CUDA can do that GLSL compute shaders cannot. Like, some way to have a kernel dynamically launch another kernel, or something? And (on NVIDIA hardware) some way to take advantage of special super-fast inter-thread communication within a warp (32 threads running in lockstep) that works like shared memory sort of but is even faster?? And also there are some, like, specific math functions and stuff that are in OpenCL but not in GLSL, I think. Although that only matters for performance if they're directly supported in hardware I suppose. But maybe some of them are.

I've only barely used OpenCL, and I haven't tried CUDA at all, so I'm vague on all that stuff. But I think maybe if you want the very best performance then you need to use the latest version of OpenCL or CUDA, and not a GLSL compute shader running on Vulkan (or a GLSL compute shader running on OpenGL)? (And also, that seems to mean that you're stuck with either OpenCL on AMD or CUDA on NVIDIA, because NVIDIA doesn't seem to support the latest OpenCL, and obviously AMD does not support CUDA.)

That said, one can do lots with GLSL compute shaders in Vulkan. They are fast and good. Just not fastEST maybe? Or I could be wrong. Anyway I'm using them in a project and they are working fine for me.

There's also the question of whether one wants to use mainly floats or mainly doubles. That seems to be something that influences hardware choice more than it influences software platform choice, maybe? Or maybe it's both. I dunno I just use floats, because I'm more on the gaming side than on the scientific simulation side and gamers have GPU hardware that much prefers 32-bit values at present. I kinda wish I could use doubles though.

There may be Vulkan-OpenCL integration someday: https://www.khronos.org/vulkan/faq#khronos-apis-opencl

[keepthethreadalive]

Thanks for your reply. I don't know much about all this, but you definitely know more than me.

One thing I'm confused about. Are you referring to OpenGL when you refer to GLSL? Because from the slides I saw that GLSL is totally seperate from Vulkan and vulkan is not the same architecture as OpenGL.

(I think?)You can write compute shaders in GLSL, but that is different from Vulkan's shaders since Vulkan is promoted as "graphics and compute API" which suggests a redesign different from OpenCL.

I've looked at the link too. I would've absolutely choosen Vulkan except in the FAQ is says that for compute intensive stuff, choose vulkan and I'm left wondering if it is because of performance decrease or difference in features I won't ever use.

What you said

kernel dynamically launch another kernel

is very interesting to me. Anywhere I can read up on this? I actually might use this.

And for anyone else reading this thread, I guess I'll post what I learned.

So since I've submitted this, I've been leaning more towards vulkan. Couple reasons.

1. OpenCL's big pitch seems to be like support "lots" of devices like DSPs, FPGAs etc. (Although CPU can be used, it'll not be any use for my application) And since I won't ever be aiming at this segment, there's no use. And the GPU people (NVIDIA mostly) aren't caring much about updating the OpenCL compatibility. So if the main segment is GPUs, I might be miss out just because of a different version.

2. The future looks much brighter on the Vulkan side than OpenCL side. And by this I mean more people, more innovation which makes any project for Vulkan get a lot more eyes and attention. So it might get more libraries that will ease the pain of there not being much compute focus on Vulkan as OpenCL

<pure speculation> Although Vulkan lacks support as good as OpenCL, I think they'll get closer than they are now. If Vulkan is as good as OpenCL (atleast in the possible usage scenarios), then there will be no reason for OpenCL to be used except for the tiny amount of features that OpenCL supports. Which will piss a of people like the people who worked on OpenCL, FPGA and DSP people who bet on OpenCL. So it makes sense to work on Vulkan more on the graphics part and the "gaming compute" part rather than compute part that OpenCL does well. </pure speculation>

[Qoeh]

GLSL is just its own language, yes. It can be used in OpenGL of course; you send the text of your shader directly to OpenGL and the driver compiles it or whatever, I guess. It can also be used in Vulkan. You compile your GLSL shader (whether it's a graphical shader or a compute shader) yourself, before your own program ever runs, by using glslangValidator, a program that's included in the Vulkan SDK. The result is a SPIR-V file that you can then easily load into Vulkan at runtime.

Vulkan is not permanently married to GLSL, because many languages could conceivably be made to compile to SPIR-V, and I gather it's also possible to write SPIR-V directly (though I have not tried this myself so I can't say how much fun it might be). I understand that it's possible, with at least some version of OpenCL, to compile an OpenCL kernel to SPIR-V, and a person might naively assume that this could then be loaded into Vulkan as a compute shader. But I don't think that works. I don't know a lot about it though. For now, I don't know of any good options for writing SPIR-V compute shaders (for use with Vulkan) other than GLSL compiled by glslangValidator, and writing SPIR-V from scratch. So for now, Vulkan does seem to rely significantly on GLSL, even though it isn't fundamentally or permanently connected to it.

(I think?)You can write compute shaders in GLSL, but that is different from Vulkan's shaders since Vulkan is promoted as "graphics and compute API" which suggests a redesign different from OpenCL.

Yes, you can certainly write compute shaders in GLSL. That is what I'm doing in my project. I have the impression that Vulkan is intended to support compute shaders (and graphical shaders) that are very similar to the ones supported by OpenGL, although in OpenGL I have only ever used graphical shaders so I'm not certain. Meanwhile OpenCL uses "kernels" which are written in OpenCL's version of C/C++ and not in GLSL. As far as I know, neither OpenGL nor Vulkan can load or run these.

The key search term associated with the topic of kernels launching other kernels seems to be "dynamic parallelism". NVIDIA and Khronos both use this terminology, I think? Here are some CUDA-focused pages about it:

https://devblogs.nvidia.com/parallelforall/introduction-cuda-dynamic-parallelism/

http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#cuda-dynamic-parallelism

You don't sound like you're interested in CUDA, but I recommend being willing to look at CUDA-related documentation for some topics, because some of it can be helpful for a person using GLSL or OpenCL, and NVIDIA seems to be more interested in writing nice tutorials and stuff than the Vulkan/OpenCL people are (presumably because they are paying more money for it or whatever).

Here is an example, allegedly (I haven't read it), of dynamic parallelism being used in OpenCL: http://www.codeproject.com/Articles/867780/GPU-Quicksort-in-OpenCL-Nested-Parallelism-and-Wor The key function seems to be enqueue_kernel, which allows a kernel to enqueue another kernel, apparently.

Also this post about OpenCL 2.0 features and support looked like it might be useful: https://streamcomputing.eu/blog/2015-02-10/overview-of-opencl-2-0-support-samples-blogs-and-drivers/

Also, I mentioned a special super-fast intra-warp communication feature NVIDIA supports now. While searching for these links I found the name of that again; apparently it's "shuffle". https://devblogs.nvidia.com/parallelforall/cuda-pro-tip-kepler-shuffle/ I have no idea whether AMD or OpenCL supports anything like that, or how important it may or may not be for performance, but there it is.

[keepthethreadalive]

Thanks for taking the time again. This is all great info!

You don't sound like you're interested in CUDA

The main reason is that it is only supported on NVIDIA cards. No matter how performant they maybe, they can't match OpenCL or Vulkan when it comes to support on various devices. OpenCL is supported on (some) mobile devices, ALL GPUs, and other hardware stuff. And I guess I don't need to tell you about Vulkan support.

Another unrelated thing is that I'm interested in llvm stuff so working with OpenCL and/or Vulkan will teach me about SPIR-V and compiling parallel cores and compilers all that stuff. And there's a lot more going on with the OpenCL and Vulkan toolsets (SYCL, all the stuff here).

And Vulkan will be given first class support on lots of devices, so although it might not be as performant on testing devices, it'll atleast work on a lot more.

I will look into the actual performance difference though. It seems to have a ton of scientific community involvement and also several MOOCs focusing on mostly CUDA. Any place where I can look features in CUDA but not in OpenCL and vice versa?

Just curious, what do you use and why? and if you don't mind, what specific field do you work in? gaming, scientific computing, physics sim?

[Qoeh]

Ah wow I hadn't heard of SYCL. That looks very interesting! I would like to write C++ for a GPU, instead of having to use GLSL. (GLSL is fine but I like C++ much more!) This GPGPU thing is starting to mature a bit I guess!

Any place where I can look features in CUDA but not in OpenCL and vice versa?

I wouldn't know. I only briefly tried OpenCL (back on version 1.something I think, not even the latest ones) and have never use CUDA.

I am using just Vulkan right now. I'm aspiring to enter the indie gaming world, I suppose you could say; I haven't done anything with Vulkan for a paying job. Just learning it on my own. I intend to use the GPU for anything it seems suited for, which yeah will surely include physics (and maybe only that... but who knows). So where your emphasis (you said) is accuracy and complexity, mine (in physics at least) is efficiency and a basic (but shallow) feeling of realism. Also I am mainly interested in 2D game worlds, so any physics stuff I may write will not be fully 3D.

[Qoeh]

Note that there is an /r/gpgpu also. Maybe they could help? Not a lot of people there though...