66

I know OpenCL gives control of the GPU's memory architecture and thus allows better optimization, but, leaving this aside, can we use Compute Shaders for vector operations (addition, multiplication, inversion, etc.)?

simon.denel
  • 780
  • 6
  • 23
Maiss
  • 1,641
  • 4
  • 18
  • 23

2 Answers2

70

In contrast to the other OpenGL shader types, compute shaders are not directly related to computer graphics and provide a much more direct abstraction of the underlying hardware, similar to CUDA and OpenCL. It provides customizable work group size, shared memory, intra-group synchronization and all those things known and loved from CUDA and OpenCL.

The main differences are basically:

  • It uses GLSL instead of OpenCL C. While there isn't such a huge difference bewteen those programming languages, you can however use all the graphics-related GLSL functions not available to OpenCL, like advanced texture types (e.g. cube map arrays), advanced filtering (e.g. mipmapping, well Ok, you will probably need to compute the mip-level yourself), and little convenience things like 4x4 matrices or geometric functions.
  • It is an OpenGL shader program like any other GLSL shader. This means accessing OpenGL data (like buffers, textures, images) is just trivial, while interfacing between OpenGL and OpenCL/CUDA can get tedious, with possible manual synchronization effort from your side. In the same way integrating it into an existing OpenGL workflow is also trivial, while setting up OpenCL is a book on its own, not to speak of its integration into an existing graphics pipeline.

So what this comes down to is, that compute shaders are really intended for use within existing OpenGL applications, though exhibiting the usual (OpenCL/CUDA-like) compute-approach to GPU programming, in contrast to the graphics-approach of the other shader stages, which didn't have the compute-flexibility of OpenCL/CUDA (while offering other advantages, of course). So doing compute tasks is more flexible, direct and easy than either squeezing them into other shader stages not intended for general computing or introducing an additional computing framework you have to synchronize with.

Compute shaders should be able to do nearly anything achievable with OpenCL with the same flexibility and control over hardware resources and with the same programming approach. So if you have a good GPU-suitable algorithm (that would work well with CUDA or OpenCL) for the task you want to do, then yes, you can also do it with compute shaders, too. But it wouldn't make that much sense to use OpenGL (which still is and will probably always be a framework for real-time computer graphics in the first place) only because of compute shaders. For this you can just use OpenCL or CUDA. The real strength of compute shaders comes into play when mixing graphics and compute capabilities.

Christian Rau
  • 45,360
  • 10
  • 108
  • 185
  • 18
    Don't forget about the precision guarantees that OpenCL provides that GLSL explicitly does *not*. – Nicol Bolas Apr 08 '13 at 11:00
  • @NicolBolas You mean for arithmetic operations and functions? – Christian Rau Apr 08 '13 at 12:50
  • 1
    Yes. Floating-point precision is very different between the two. – Nicol Bolas Apr 08 '13 at 13:54
  • @NicolBolas Could you elaborate a bit where the particular differences lie or what is not guaranteed by GLSL. I think it at least is guaranteed to work with IEEE floats, isn't it? So it's *"just"* the rounding of arithmetic operations and the permissible optimizations of floating point expressions that are unspecified? Too lazy to dig into the specifications, I admit. – Christian Rau Apr 08 '13 at 13:57
  • These are my intents; doing both graphics rendering and computations in parallel. I believe you can work with IEEE double/floats since OpenGL 4.0. Thanks a lot. – Maiss Apr 08 '13 at 16:18
  • 5
    There are extensions that grants IEEE precisions and to disable operation re-ordering. – Luca Apr 09 '13 at 17:39
  • What about performance? Will the "same" program in GLSL compute shader runt as fast as in OpenCL in general? Are there any limitations for program size/complexity? – Mr. Developerdude Sep 03 '16 at 23:30
  • @LennartRolland That is quite device/driver dependent, though. They *should* run equally fast, since you're using the same hardware in the same way. However, *if* they really get implemented and optimized the same is highly driver dependent. I admittedly don't know about aby bigger differences of program size/complexity off the top of my head right now, though. There are a few differences by the mere fact that there's some features one supports that the other doesn't support, but those are more detailed/advanced features, while the answer is kept largely general. – Christian Rau Sep 03 '16 at 23:34
  • 2
    Those interested in OpenGL arithmetic precision guarantees should regard the ARB_shader_precision extension, introduced in OpenGL 4.1. See: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_shader_precision.txt – Droid Coder Aug 11 '19 at 11:22
4

Look here for another perspective. Summarizing:

Yes, OpenCL already existed, but it targets heavyweight applications (think CFD, FEM, etc), and it is much more universal than OpenGL (think beyond GPUs... Intel's Xeon Phi architecture supports >50 x86 cores).

Also, sharing buffers between OpenGL/CUDA and OpenCL is not fun.

Rahul Banerjee
  • 2,343
  • 15
  • 16
  • 1
    In practice, a High-end GPU is >>40 time more capable than a High-end CPU to solve a parallelizable problem, in matrix computing, to be more specific. I don't really care about the CPU capability for now. So to go back to my question, can we do lets say Matrix Inversion with compute shaders? And how much work is needed in comparison to OpenCL? – Maiss Apr 07 '13 at 22:43
  • 1
    AFAIK, parallel algorithms exists for only inverting *sparse* matrices and these are sufficiently complex that you'd probably want to write them in C99 (OpenCL's kernel language). – Rahul Banerjee Apr 07 '13 at 22:49
  • 2
    You can do many types of computation in OpenGL's compute shaders that would be similar to OpenCL, with the major difference that OpenGL uses _GLSL_ (The OpenGL Shading Language) as its kernel language, as compared to OpenCL's C99 dialect. There's no limitation for doing matrix computations (e.g., only working with sparse matrices), and in particular cases, you may be able to use block-based matrix algorithms that leverage some of GLSL's native matrix operations. – radical7 Apr 08 '13 at 00:59