[Mesa-dev] Using --enable-opencl-icd by default and deprecating the toggle

[Emil Velikov]

On 3 October 2017 at 05:31, Jan Vesely <jan.vesely at rutgers.edu> wrote:
> On Fri, 2017-09-29 at 16:14 +0100, Emil Velikov wrote:
>> Hi all,
>>
>> Currently nearly all the distributions I've seen* enable and use the ICD.
>> Only Gentoo does not use it, but manages the OpenCL.so conflicts via eselect.
>
> to be fair, you can install and eselect ocl-icd. eselect switches
> libOpenCL.so providers, and mesa is one of them.
>
Not sure I follow.

Can one eselect ocl-icd alongside and actual implementation (say Mesa)?

1) If not - you'll only have a dummy frontend, without an actual implementation.
2) Otherwise, the flow is as below:
 App -> opencl loader (ocl-icd's libOpenCL.so) -> opencl backend icd
file -> opencl backend implementation (libMesaOpenCL.so)

As Mesa is build without --enable-opencl-icd there's no icd file and
no libMesaOpenCL.so.
Mesa will only produce libOpenCL.so which will clash(?) with the ocl-icd one.

So in a tl;dr: things seem flaky and/or broken.

>>
>> They have the ocl-icd library as a separate option, which makes me
>> wonder how that's supposed to work. After all, for it to work the
>> vendor package should:
>> a) provided a binary not called libOpenCL.so (it could be called like
>> that, but must be outside of ld's search path)
>> b) provide a $foo.icd file, listing the ICD file/path name
>>
>> Most likely I'm having a dull moment somewhere and things work just fine.
>>
>> Considering that the --enable-opencl-icd is almost always set, I think
>> we should change the default.
>
> Dieter recently reported that building with --enable-opencl-icd
> produces broken libOpenCL.so library (in addition to client
> libMesaOpenCL.so) [0]. It'd be nice if mesa libOpenCL.so could act as
> ICD loader when built with --enable-opencl-icd.
>
I've shared some ideas in the thread.

That said - deprecating/removing the toggle is a no-go for now, so
lets just flip the switch.

Thanks
Emil