OpenCL 1.1 Turns Five, Open-Source CL Adoption Still Disappointing

[phoronix]

Phoronix: OpenCL 1.1 Turns Five, Open-Source CL Adoption Still Disappointing

This week marked five years since the release of OpenCL 1.1. While much time has passed, the open-source OpenCL drivers and free software adoption of the Open Computing Language remains arguably poor...

http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-1.1-Five-Years

[zanny]

OpenCL is yet another chicken and egg problem.

Nobody is writing it into their software stack because its unsupported for the most part, and until you can effectively guarantee some minimum degree of support. Nobody wants to be writing if(cl) <huge 1k lines of OCL shaders> else <1k lines of CPU bound mumbo>. But until you have the current Ubuntu LTS shipping, say, OpenCL 1.2 support for every modern CPU / GPU combo, nobody can start using it, because then its just a very time consuming optimization.

Yet nobody is implementing support or giving a crap about making it pervasive because nobody is using it, and as per with pretty much everything else the Linux desktop market segment is too small to motivate AMD / Intel to throw money at the problem until its solved.

Its probably complexities fault. OpenCL, like OpenGL, like CUDA, are all very complex APIs to implement, and right now Intel and AMD are sharing basically nothing between their work towards it.

[schmidtbag]

OpenCL is yet another chicken and egg problem.

Nobody is writing it into their software stack because its unsupported for the most part, and until you can effectively guarantee some minimum degree of support. Nobody wants to be writing if(cl) <huge 1k lines of OCL shaders> else <1k lines of CPU bound mumbo>. But until you have the current Ubuntu LTS shipping, say, OpenCL 1.2 support for every modern CPU / GPU combo, nobody can start using it, because then its just a very time consuming optimization.

Yet nobody is implementing support or giving a crap about making it pervasive because nobody is using it, and as per with pretty much everything else the Linux desktop market segment is too small to motivate AMD / Intel to throw money at the problem until its solved.

Normally I'd agree, but just about everything outside of home PCs that demands openCL already supports it. That being said, I think Catalyst has such good openCL support because of GPGPU servers. I'm guessing these servers are the main source of profit for AMD linux. Since Catalyst's openCL is feature-complete and has great performance, I don't really see why the open source devs would give openCL much priority.

Nvidia meanwhile doesn't care about openCL because they want people to use CUDA. Even though beignet is pretty good, intel GPUs aren't. So for anyone who cares about openCL, that really limits users to strictly modern AMD GPUs with catalyst. While I'm sure there are plenty of servers that are ok with that, that's a pretty low percentage of PC users.

In conclusion, Nvidia is not going to promote openCL, intel isn't useful enough, and AMD already has good openCL support. So if people want to see it get anywhere, it's up to the application developers to make it popular.

[dragorth]

I think there are a few things that are starting to converge that will make OpenCL a much larger focus.

The first is OpenCL 2.1, SPIR-V and Vulkan. This three pronged effort effectively forces anyone that supports Vulkan to supoort OpenCL. You will support most of the spec with Vulkan, and the little that is left will require little effort compared to the whole.

Next is AMD's focus on HSA. AMD is bringing to the desktop something mobile has in various forms already, one coherent memory mapping space for programmers. This work can benefit Intel as well as Nvidia on the mobile side of the equation. Vulkan takes advantage of this for supported platforms, as well as OpenCL 2 and SPIR-V, to speed up compute heavy tasks.

Then we have the SPIR-V LLVM effort, essentially providing every LLVM backed language support for GPGPU as well as the possibilty to write C++ code and convert it to OpenCL later on.

Not to mention the support AMD has worked on for C++ AMP in LLVM, which should be able to take advantage of SPIR-V, meaning that any program that is written in C++ can be easily converted to use OpenCL.

And we now have Cycles support for OpenCL on AMD. With Blender being one of the huge success stories of the FOSS movement, its high profile is able to move developers to implement features that improve the overall experience for everyone.

Nvidia doesn't really want to support OpenCL, but with the advent of Vulkan, I believe they will be forced to support OpenCL 2.1 just to compete with the Open source drivers, as they will most likely add support for OpenL 2.1 as they are supporting SPIR-V.

Of course, all of this is the best scenario, but I believe the stars are aligning for this to happen.

[emblemparade]

What's unfortunate is that app developers don't make enough use of it, because so many apps that do CPU-bound work could reap a lot of benefits.

But, the fact is that many app developers don't even make use of OpenMP, which makes it almost trivial to optimize C/C++ code for multi-core loads. My experience with OpenCL showed me that it's really not too hard to make use it, especially if you're already writing C code. But, not quite as easy as OpenMP, and you still need to write a codepath (with its own testing) for platforms that don't support OpenCL. Perhaps OpenCL is just too hard to use, still, and needs something similar to OpenMP to make integration truly trivial.

It's also surprising that game developers don't use it, too. In my game, I added OpenCL support for procedural terrain generation, and got that code running 100 times faster than on the multi-core CPU! I think the move to Vulkan will encourage more game developers to use it: because Vulkan is lower level, game programmers will have to learn more nuts and bolts, and do more old-fashioned coding (like they do with shaders in OpenGL). Applying that knowledge to OpenCL will by trivial. Actually, as I understand it, Vulkan and next-gen OpenCL will pretty much converge in much of the API pipeline and coding language.

NVIDIA *does* support OpenCL. Perhaps they just promote it as much as CUDA. But, as others have stated, the move to Vulkan is changing all of this

[schmidtbag]

It's also surprising that game developers don't use it, too. In my game, I added OpenCL support for procedural terrain generation, and got that code running 100 times faster than on the multi-core CPU! I think the move to Vulkan will encourage more game developers to use it: because Vulkan is lower level, game programmers will have to learn more nuts and bolts, and do more old-fashioned coding (like they do with shaders in OpenGL). Applying that knowledge to OpenCL will by trivial. Actually, as I understand it, Vulkan and next-gen OpenCL will pretty much converge in much of the API pipeline and coding language.

I'm not entirely sure about openCL but CUDA is used in games, in the form of physx. Generally speaking, I'm not a fan of openCL or CUDA being used in games unless it takes advantage of a secondary GPU or an IGP, or unless it's for a one-time task. Games are already very GPU intensive and most hardly take advantage of more than 4 CPU cores.

[oleid]

I'm not entirely sure about openCL but CUDA is used in games, in the form of physx. Generally speaking, I'm not a fan of openCL or CUDA being used in games unless it takes advantage of a secondary GPU or an IGP, or unless it's for a one-time task. Games are already very GPU intensive and most hardly take advantage of more than 4 CPU cores.

When it comes to OpenCL, the user can usually decide whether to run the kernel on a GPU or a CPU.

[dungeon]

When it comes to OpenCL, the user can usually decide whether to run the kernel on a GPU or a CPU.

That is "cool", when it comes to OpenGL users can decide if they want to use swrast

[Marc Driftmeyer]

When Bullet 3 is finally released lots of Game Developers will incorporate that OpenCL optimized Physics Stack into their products.

[dragorth]

What's unfortunate is that app developers don't make enough use of it, because so many apps that do CPU-bound work could reap a lot of benefits.

But, the fact is that many app developers don't even make use of OpenMP, which makes it almost trivial to optimize C/C++ code for multi-core loads. My experience with OpenCL showed me that it's really not too hard to make use it, especially if you're already writing C code. But, not quite as easy as OpenMP, and you still need to write a codepath (with its own testing) for platforms that don't support OpenCL. Perhaps OpenCL is just too hard to use, still, and needs something similar to OpenMP to make integration truly trivial.

It's also surprising that game developers don't use it, too. In my game, I added OpenCL support for procedural terrain generation, and got that code running 100 times faster than on the multi-core CPU! I think the move to Vulkan will encourage more game developers to use it: because Vulkan is lower level, game programmers will have to learn more nuts and bolts, and do more old-fashioned coding (like they do with shaders in OpenGL). Applying that knowledge to OpenCL will by trivial. Actually, as I understand it, Vulkan and next-gen OpenCL will pretty much converge in much of the API pipeline and coding language.

NVIDIA *does* support OpenCL. Perhaps they just promote it as much as CUDA. But, as others have stated, the move to Vulkan is changing all of this

If you want something OpenMP like, take a look at C++ AMP. You select out portions of code that can benefit from GPGPU, wrap it in an AMP keyword, tell it the feature set it uses, currently CPU or GPU to let the compiler know where it can run, and it can be compiled to either DirectX Compute with Visual Studio, or OpenCL with an AMD branch of LLVM.

AMD also has a library that will take care of some common STL functions that can easily be parallelized and turns them into OpenCL calls, to help automate some basic wins.

What many engines do is to do some of that in GLSL code, rather than OpenCL, as both are using the same hardware, and GLSL has graphics specific built ins that make it slightly easier for them.

Nvidia barely supports OpenCL, and they will tell you they support it if you ask, but they actually push CUDA.