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 of GLSL, without its programmatic limitations.
I think there are a few reasons GLSL is going to stick around. First, the syntax is very simple for shader development with features like swizzling built into the language. Second, there has been a bit of a performance penalty sharing data between OpenGl and CUDA/OpenCL. This may go away in the future. Third, some of the limitations associated with GLSL keep it very fast. Write limitations, for example, in current gen hardware and GL make sure writes are coherent. If you opened up GLSL to be more generic and powerful, you’d lose a bit of these benefits. I’ve seen several presentations in regards to CUDA, where the group had a slightly faster version in straight OpenGL/GLSL. While the former was easier to program, it wasn’t quite as fast as the latter.
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 of GLSL, without its programmatic limitations.
Um, why? You lose a lot of important fixed function stuff (triangle interpolation, specialized caches, etc). You may not have the limitations of GLSL, but you won’t have the performance of OpenGL either. For most people using OpenGL, that’s not a particularly good tradeoff.
Intel tried something like this with Larrabee, and that was hardware-based. They couldn’t release it because it simply wasn’t performance/price competitive with competing platforms. Granted, they’re still trying, but they delayed it for several years until it actually functions.
The point of GLSL is to provide shaders, i.e. little bits of code acting on vertices, fragments, etc for the purpose of rasterization, i.e. to draw pictures at the end of the day.
OpenCL is for computing stuff, i.e crunching numbers.
Different tools for different jobs. Yes, one can use OpenCL to make a rasterizer, but GPU’s have dedicated hardware to:
- rasterize lines and triangles
- perform LOD for texture lookups and texture filtering
- (now) tessellation
which are all “draw picture” things. As such, for a fixed piece of hardware with reasonable drivers for GL and CL, one would definitely find the GL drawer will beat a CL drawer when they draw the same thing (assuming the GL drawer is made in a reasonable way).
Take a look into GL_NV_shader_buffer_store.txt and GL_EXT_shader_image_load_store.txt for crazy write access on hardware out now.
For crazy read access from last generation take a look at GL_NV_shader_buffer_load.txt
These three extensions lift most of the “arr, GLSL not flexible enough for me”. The write access ones need to be used with care though!
Why? Because people writing games don’t need it. GLSL does what they need, which is taking over specific parts of the pipeline.
You’ve already gotten some good responses here.
Assuming your app already uses OpenGL/GLSL. and accepting that GLSL makes some jobs inherently easier, it’s worth considering when you’d would want to additionally use OpenCL. If you can accelerate your algorithm by making smart use of shared memory on the GPU shader cores, use OpenCL. Otherwise, just use GLSL.