I have been told there is no performance difference if you are skilled enough when it comes to gpu computing. And cuda only performs better because nvidia wants it to. I have also read graphic api's compute shaders are not as good as OpenCL/cuda. I don't understand how are compute shader different from Cuda/OpenCL and why would they be slow (if they are). I wanted to know this because OpenCL is difficult to understand and setup for me. Will there be a performance hit on using OpenGL compute shader and will Vulkan compute shader perform better than OpenGL's?

  • 1
    $\begingroup$ Depends on what you wanna do. For algorithms tied to rendering operations compute shaders are the way to go. For general purpose computing its OpenCL/Cuda. Check this thread out. Also OpenCL exposes more memory details and has more precision guarantees. I once made a raytracer on both compute shader and OpenCL and I found the openCL one to be a lot faster. There could be a variety of reasons for it though. $\endgroup$ Mar 16, 2021 at 9:51
  • 2
    $\begingroup$ I think Noah hit the nail on the head here, the hardware this runs on will have a much bigger impact on performance then the API. Other factors to help you narrow in on a choice: Vulkan tends to be easier to setup and use for compute shaders then graphics work, and gives better control over CPU level parallelism then OpenGL. So many small jobs tend to be easier to manage under vulkan. But OpenGL provides great convenience and if your compute shaders ten to be large monolithic runs that saturate the GPU then OpenGL is easier to setup and maintain and will give effectively, the same performance. $\endgroup$
    – pmw1234
    Mar 16, 2021 at 11:40

1 Answer 1


In general, you should not see significant performance differences running identical compute shaders via one API vs. another; in the end they’re running the same instructions on the same hardware. It’s possible for vendor-provided toolkits like CUDA or MetalPerformanceShaders to have more efficient implementations of a given algorithm on that vendor’s hardware than a more generic version of the algorithm, because they’ve been designed and tuned for the strengths of that hardware, but there’s nothing in principle that would prevent you from developing the same efficiencies on your own with enough optimization work.

Long story short: work with whichever API you find easiest to use, and invest some time in learning how to profile and tune your code for the hardware you plan to run it on.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.