OpenGL vs OpenCL, which to choose and why?

Question

What features make OpenCL unique for choosing OpenGL using GLSL for calculations? Despite graphically related terminology and practical data types, is there any real obstacle to OpenGL?

For example, evaluating a parallel function can be done by rendering a texture using other textures. Reducing operations can be done by iteratively rendering to smaller and smaller textures. On the other hand, random access to a record is not possible in any effective form (the only way to do this is to convert triangles using vertex data with texture). Is this possible with OpenCL? What else is possible with OpenGL?

Answer 1

OpenCL is designed specifically for computing. When doing scientific computing using OpenGL, you always need to think about how to map your computational problem to the graphics context (i.e., speak in terms of textures and geometric primitives like triangles, etc.) to get your calculations.

In OpenCL, you simply formulate calculations with the calculation kernel in a memory buffer, and you're good to go. This is actually a BIG victory (saying that from the point of view to think through and implement both options).

The memory access patterns are the same (your calculations are still happening on the GPU, but GPUs are becoming more and more flexible these days). A.

But what else do you expect than using more than a dozen parallel "CPUs" without understanding your head about how to translate - for example, (silly example) Fourier to triangles and quadrants ...?

Answer 2

What has not yet been mentioned in any answers is the speed of execution. If your algorithm can be expressed in OpenGL graphics (for example, without scattered records, without local memory, without workgroups, etc.), this will very often work faster than OpenCL. My specific experience in this is to create filters for image filtering (collection) on AMD, nVidia, IMG and Qualcomm GPUs. OpenGL implementations invariably run faster even after tight optimization of the OpenCL kernel. (aside: I suspect this is due to the fact that for many years the hardware and drivers have been specifically tuned for graphics-oriented workloads.)

My advice will be that if your computing program feels that it displays the graphic domain well, then use OpenGL. If not, OpenCL is more general and simpler to express computational problems.

Another point to mention (or ask) is whether you write as an amateur (i.e. for yourself) or commercially (i.e. for distribution to others). Although OpenGL is supported almost everywhere, OpenCL does not fully support mobile devices, and imho is unlikely to appear on Android or iOS in the next few years. If broad cross-platform compatibility with a single code base is the goal, then OpenGL can be imposed on you.

Answer 3

What features make OpenCL unique for choosing OpenGL using GLSL for calculations? Despite graphically related terminology and practical data types, is there any real obstacle to OpenGL?

Yes: this is a graphical API. Therefore, everything that you do in this should be formulated on these conditions. You should pack your data in the form of "rendering". You must figure out how to handle your data in terms of attributes, uniform buffers, and textures.

With OpenGL 4.3 and OpenGL ES 3.1 calculate shaders , things get a little more confusing. The computational shader is able to access memory through SSBOs / Image Load / Store in the same way for OpenCL operations (although OpenCL offers actual pointers, but GLSL does not). Their interaction with OpenGL is also much faster than OpenCL / GL interop.

Nevertheless, computational shaders do not change one fact: OpenCL computation operations work with completely different accuracy than using OpenGL shaders. GLSL floating point precision requirements are not very stringent, and OpenGL ES is even less stringent. Therefore, if the accuracy of floating point calculations is important for your calculations, OpenGL will not be the most efficient way to calculate what you need to calculate.

In addition, OpenGL shader processors require 4.x compatible hardware, while OpenCL can run on much lower hardware.

Also, if you are doing calculations co-opting with the rendering pipeline, OpenGL drivers still assume that you are rendering. Therefore, he will make optimization decisions based on this assumption. It optimizes the allocation of shader resources, provided that you draw an image.

For example, if you pass a floating-point framebuffer, the driver may simply decide to provide you with the R11_G11_B10 framebuffer, because it detects that you are not doing anything with alpha, and your algorithm may tolerate lower precision. If you use loading / saving images instead of a framebuffer, you are unlikely to get this effect.

OpenCL is not a graphical API; This is a computational API.

In addition, OpenCL gives you access to more materials. This gives you access to memory levels that are implicitly related to GL. Some memory can be shared between threads, but individual instances of shaders in GL cannot directly affect each other (outside the Image Load / Store, but OpenCL runs on hardware that does not have access to this).

OpenGL hides what hardware does behind abstraction. OpenCL provides you with almost what is happening.

You can use OpenGL to do arbitrary calculations. But you do not want; there is no completely viable alternative yet. Compute in OpenGL to serve the graphics pipeline.

The only reason for choosing OpenGL for any calculation operation without rendering is the support of equipment that cannot run OpenCL. Currently, this includes many mobile devices.

Answer 4

One notable feature is the scattered recordings, the other is the lack of Windows 7 smartness. Windows 7, as you probably know, will kill the display driver if OpenGL doesn't paint over for 2 seconds or so (don't nail me at the exact time, but I think it's 2 seconds). This can be annoying if you have a long operation.

In addition, OpenCL obviously works with a much wider variety of hardware than just a graphics card, and it does not have a rigid graphics-oriented pipeline with “artificial limitations”. It’s easier (trivial) to run multiple parallel threads of commands.

Answer 5

Although OpenGL is currently the best choice for graphics, it is not permanent.

It is possible that OpenGL will eventually merge as an OpenCL extension. The two platforms are about 80% the same, but have different syntactic quirks, different nomenclature for about the same hardware components. This means two languages ​​to learn, two APIs to define. Graphics driver developers would prefer merging because they no longer have to develop for two separate platforms. This leaves more time and resources for debugging the driver .;)

Another thing to keep in mind is that the origins of OpenGL and OpenCL are different: OpenGL started and gained momentum during the early days with a fixed pipeline across the network, and was slowly added and deprecated as the technology evolved. OpenCL, in some ways, is an evolution of OpenGL in the sense that OpenGL began to be used for digital processing, since the (unplanned) flexibility of GPUs is acceptable. "Graphics vs. Computing" is more of a semantic argument. In both cases, you are always trying to match your mathematical operations with equipment with maximum performance. There are parts of the GPU hardware that will not use vanilla CL, but this will not support a separate extension.

So how can OpenGL work under the CL? In particular, triangle rasterizers can be highlighted as a special CL task. Special GLSL functions can be implemented in vanilla OpenCL, and then redefined for hardware accelerated instructions by the driver during kernel compilation. Writing a shader in OpenCL, while waiting for the library to expand, doesn't sound like a painful experience.

To call one, to have more functions than the others, does not make much sense, since they both gain 80% of the same functions, only under different nomenclatures. Saying that OpenCL is not suitable for graphics because it is intended for computing does not make sense since graphic processing is calculated.

Answer 6

Another important reason is that OpenGL \ GLSL is only supported on graphics cards. Although multi-core use began with the use of graphics hardware, many hardware manufacturers are working on a multi-core hardware platform designed for computing. For example, see Intels Knights Corner.

Developing code for computing using OpenGL \ GLSL will not allow you to use any equipment that is not a graphics card.

Answer 7

OpenCL (in version 2.0) describes a heterogeneous computing environment in which each component of the system can produce and consume tasks created by other system components. There are no more requirements for the processor, GPU (etc.) - you only have Host and Device (s).

OpenGL, by contrast, has a strict separation between the CPU, which is a task producer and the GPU, which is a task consumer. This is not bad, since less flexibility provides more performance. OpenGL is an even narrower tool.

Answer 8

Well, like OpenGL 4.5, these are the features of OpenCL 2.0 that OpenGL 4.5 is not (as far as I could tell) (this does not apply to the functions that OpenGL has that OpenCL does not):

Developments

The best nuclear technology

Blocks

Workgroup functions: work_group_all and work_group_any work_group_broadcast: work_group_reduce work_group_inclusive / exclusive_scan

Kernel launch kernel

Pointers (although if you are running on a GPU this probably doesn't matter)

A few mathematical functions that OpenGL does not have (although you could create them yourself in OpenGL)

Shared virtual memory

(Optional) Compiler options for kernels

Easily select a specific GPU (or otherwise)

Can work on CPU if there is no GPU

More support for those niche hardware platforms (like FGPA)

On some (all?) Platforms, you do not need a window (and its context binding) to perform the calculations.

OpenCL allows a little more control over the accuracy of calculations (including some of these compiler options).

Many of them are mainly associated with improved interaction with the processor and the GPU: events, shared virtual memory, pointers (although they can potentially benefit other things).

OpenGL was able to sort things in different areas of Client and Server memory, as many other messages were made here. Now OpenGL has better memory protection and atomic support and allows you to distribute things in different registers in the GPU (about the same extent as OpenCL). For example, you can share registers in a local computing group now in OpenGL (using something like LDS (local shared resource) of AMD GPUs (although this feature only works with OpenGL shader computing at this time). OpenGL has more efficient implementations on some platforms (such as Linux open source drivers.) OpenGL has access to more hardware with fixed functionality (as other answers said). Although it’s true that hardware can sometimes be fixed fixed functionality (for example, Crytek uses a “software” depth buffer implementation) fixed function hardware can manage memory perfectly (and usually much better than someone who doesn’t work on a GPU hardware company) and in most cases is significantly superior I have to admit that OpenCL has pretty good fixed functional support for textures, which is one of the main areas of the fixed OpenGL function.

I would say that OpenGL has become at least a little less abstract lately, and there is talk of a complete reorganization of OpenGL (called OpenGL NG media) that removes a lot of abstraction and more (e.g. more functions like Mantle). you heard about it.

I would say that Intels Knights Corner is an x86 GPU that controls itself. I would also like to argue that OpenCL 2.0 with its texture features (which are actually found in smaller versions of OpenCL) can be used for the same level of performance that user 2746401 suggested.

Answer 9

In addition to the existing answers, OpenCL / CUDA is not only more suitable for the computing area, but also does not abstract the main equipment too much. In this way, you can profit from things like shared memory or access to shared memory access, which otherwise would have made it difficult to actually implement the shader (which in itself is nothing more than a special OpenCL / CUDA core, if you want to).

Although in order to benefit from such things, you also need to learn a little about the specific hardware your kernel will run on, but do not try to explicitly take these things into account with the shader (if at all possible).

Once you do something more complex than simple Level 1 BLAS procedures, you will certainly appreciate the flexibility and versatility of OpenCL / CUDA.

Answer 10

The "function" that OpenCL is for general purpose computing, while OpenGL is for graphics. You can do something in GL (this is Turing-complete), but then you drive into the nail with the handle of a screwdriver as a hammer.

In addition, OpenCL can work not only on graphic processors, but also on processors and various specialized accelerators.