What is the point of GLSL when there is OpenCL?

Consider this the complete form of the question in the title: Since OpenCL may be the common standard for serious GPU programming in the future (among other devices programming), why not when programming for OpenGL - in a future-proof way - utilize all GPU operations on OpenCL? That way you get the advantages o开发者_开发百科f GLSL, without its programmatic limitations.

GLSL is OpenGL Shading Language. It is intended, originally, for controlling the graphics pipeline.

OpenCL, on the other hand, is the Open Computing Language. It does not control graphics, but rather computation.

The two technologies are targetting different capabilities and functionality.

That being said, moving forward, they may be very little reason to use GLSL for computation purposes. However, as of today, more vendors fully support GLSL than OpenCL, so it is still useful for computation purposes even though it is limited as that is not its core purpose, at least right now.

In the future OpenCL might be able to replace GLSL. In the meantime there are still some issues with OpenGL interop, at least with the most important (NVidia/ATI) implementations.

OpenCL will not completely replace OpenGL, though. OpenGL does a whole lot more when it comes to raster graphics. The only raster graphics primitives in OpenCL are textures/images and it can't render graphics at all.

GLSL is a "shading language". It is used for 3D rendering and has special datatypes particularly useful for that purpose (e.g. length-4 vectors and rank-4x4 matrices). The vertex and fragment shaders sit in a well-defined location inside the rendering pipeline, and they are automatically triggered on data flowing through this pipeline. The shaders also have direct access to the tranformation and projection matrices of the 3D pipeline.

OpenCL is a "compute language". It is not specially designed for the compute tasks we see in 3D rendering, but is rather a subset of C. OpenCL does have data types similar to the vectors and matrices in GLSL (float4, float16), but they are less convinient to use. Also you don't have a graphics context (which can be an advantage or a disadvantage), and the OpenCL kernel does not reside inside a 3D rendering pipeline.

If you want compute modules that are plugged into the 3D rendering pipeline and are triggered by the rendering pipeline, use GLSL. If you want general computation on the GPU outside the 3D rendering pipeline use OpenCL.

That does not mean OpenCL cannot be used to render 3D graphics. It can. In fact, you can implement your own pipeline solely in OpenCL, and then copy your drawing to the framebuffer. But if you just want to draw some 3D graphics, duplicating all the work by SGI, Nvidia, Intel and AMD engineers is probably not worth the hassle. Then it is easier to just use GLSL and get the shader plugged into a ready-to-use and fully performant OpenGL pipeline. Just consider that it was a major undertaking to write Mesa, the open-source OpenGL implementation.

@dietr: let me Eco you here! the CL/GL interoperability can harm considerably the overall performance, specially when handling a big number of object buffers (>100, for example). The context changing overhead and the lack of support for structures of buffer or pointers to buffers will just kill my apps, in such a way that I'm seriously considering the use of geometry shader to replace my opencl code. And don't fool yourself, a complete replacement of the entire opengl by opencl would require a whole recoding process which would not only be real long but also not that advantageous. Besides, as well said by the folks up-here, opengl does much more than just pipeline computation. I would say that if you intend to use CL/GL iterop, try to rewrite your code on vertex/geometry shader if you can.