GSdx-ocl: Enable OpenCL build option on Linux

[JibbityJobbity]

Easy as adding --opencl when running ./build.sh.
Removed #error hello since latest 32-bit version of OpenCL is 1.2 anyway and there isn't any significance noted for it.
This doesn't improve the renderer but I thought this might help.

[turtleli]

I don't think you need to add any of the cmake files. Are they necessary?

[mirh]

since latest 32-bit version of OpenCL is 1.2

Ehrm.. this sounds new to me. Are you sure?

[JibbityJobbity]

since latest 32-bit version of OpenCL is 1.2

Ehrm.. this sounds new to me. Are you sure?

I had the same reaction, but if you look up OpenCL 2.0 32 bit on Google, you'll find a few results, especially on the AMD community forum that OpenCL 2.0 is 32 bit only. I can confirm this when I built and ran 32-bit clinfo, platform version returns 1.2 on all of my devices where it returns 2.0 or higher in 64 bit. 😞

[Degerz]

Eh, I would remove OpenCL support entirely since it has been effectively depreciated. When you can't report bugs or they ignore them on 2 out of the 3 hardware vendors you're targeting, there's no future anymore for it ...

[mirh]

especially on the AMD community forum that OpenCL 2.0 is 32 bit only

:\

That's more like *only* there, because last time I checked it was simply them being lazy on QA. GPU_FORCE_OCL20_32BIT should unlock it iirc.

When you can't report bugs or they ignore them on 2 out of the 3 hardware vendors you're targeting

Uh, says who? Putting even aside that in linux for 2 of the vendors, the drivers are open

[JibbityJobbity]

:\

That's more like only there, because last time I checked it was simply them being lazy on QA. GPU_FORCE_OCL20_32BIT should unlock it iirc.

Agh! Forum replies I read suggested it was for the API and not just AMD's implementation of it. I can see results when I put GPU_FORCE_OCL20_32BIT, it's probably a thing but I'm not seeing any official documentation for it. I think you're onto something though since CL_VERSION_2_0 shouldn't be defined otherwise. That's assuming they're different headers for 32-bit and 64-bit.

[Degerz]

Uh, says who? Putting even aside that in linux for 2 of the vendors, the drivers are open

Nvidia does not even have a developer subforum to report OpenCL issues so good luck sending reports of OpenCL driver issues to them and as for AMD they have straight neglected their OpenCL subforum on their official developer forum for a couple of years now.

OpenCL on Linux is also a joke as well since much of the community aren't interested in developing the clover stack so progress over there has pretty much stalled and AMD exhibits the same behaviour for their ROCm OpenCL stack by ignoring issues over there as well. The only vendor that cares about OpenCL left is Intel ...

2 out of the 3 vendors ignoring OpenCL issues means that it's a dead API and should probably not use it unless the developers are okay with maintaining it to only reliably run on Intel graphics hardware!

[mirh]

Amd has not neglected opencl any more than anything else (actually, to be honest, now that I check them they seem more responsive than for when we report about opengl troubles)
Also here
Nvidia doesn't have a forum section, but from what I could see anywhere in Accelerated Computing (yes, including the cuda sections) would be cool.

[Degerz]

(actually, to be honest, now that I check them they seem more responsive than for when we report about opengl troubles)

You need to see the reality for what it truly is. At least AMD's OpenGL drivers get real bug fixes from time to time while they've effectively stopped trying to advertise OpenCL support since they haven't submitted anything to the CTS in nearly the past 4 years!

With Nvidia, there's no visibility on OpenCL and they're just doing the bare minimum to maintain compatibility. They are also the reason why OpenCL isn't getting developed any further!

OpenCL has no future whether you like it or not because maintenance for it has consistently kept getting lower over the past years. (OpenCL is the new glide at this point)

[mirh]

OCL is stagnating because it has as much features as you want, but it is an ass to program (in comparison to cuda). Nvidia has no faults there.

Check what SYCL is to see how khronos (also intel, and the foss community) are advancing it horizontally.

Also, speaking of CTS, they just this year made the humongous step to move it totally open on github. No trifles.

Speaking of amd instead............ We still have opengl bugs opened since 3-4 years.

[Degerz]

OCL's features are useless in practice if 2 of the vendors you're targeting don't have any intention of supporting CL 2 x and that especially applies to Nvidia if they're going to gate features like SVM behind CUDA rather than support it in OCL ... (Also why would features be an argument in favour of OCL when the likes of CUDA is a lower level API ?)

FOSS community effort on SYCL depends on clover stack so it's useless ...

What exactly would those GL bugs be on AMD ? FYI, performance issues or missing features don't count as 'bugs' ...

[JibbityJobbity]

Can't help but notice this is starting to get off topic from the actual PR. This is just about adding a flag on Linux to enable building with OpenCL support. Can you please take this talk over to somewhere else like the forum?

[arcum42]

The main thing I notice here is that if opencl isn't installed, it tries to build gsdx with opencl anyways and fails, whereas it would be preferable for it to either build gsdx without opencl in that case, or skip gsdx.

[JibbityJobbity]

The main thing I notice here is that if opencl isn't installed, it tries to build gsdx with opencl anyways and fails, whereas it would be preferable for it to either build gsdx without opencl in that case, or skip gsdx.

This is why we have -DENABLE_OPENCL in GSdx's CMakeLists.txt. Only thing it does if OpenCL wasn't found is it still tries to link OpenCL libraries. I'll get onto that soon.

[arcum42]

It tries to include header files for OpenCL if you enable opencl, regardless of whether it was found, which is where it errored out for me, since I apparently don't have it installed.

It's probably just a matter of adding a check to SelectPcsx2Plugins.cmake checking if the option is enabled and it's not found.

Otherwise, I see no reason not to merge it. Don't think it's far enough to need a gui option, but having a option to build it makes sense for testing.

[lightningterror]

Otherwise, I see no reason not to merge it. Don't think it's far enough to need a gui option, but having a option to build it makes sense for testing.

I'm fine with the current pr, gui option was an extra nice thing to have :)

On a related note maybe we can purge the cl_d3d9 file.

[JibbityJobbity]

It tries to include header files for OpenCL if you enable opencl, regardless of whether it was found, which is where it errored out for me, since I apparently don't have it installed.

It's probably just a matter of adding a check to SelectPcsx2Plugins.cmake checking if the option is enabled and it's not found.

Otherwise, I see no reason not to merge it. Don't think it's far enough to need a gui option, but having a option to build it makes sense for testing.

I think it's better to build without OpenCL instead of skipping GSdx. I feel like the header thing is because we're using check_lib instead of FindPackage.

[arcum42]

Now that I've had a better chance to look at this, I think we're fine. I'll go ahead and merge it, and if we need to make any adjustments, we can do that later.