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

[Jan Vesely]

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.

> 
> 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.

Jan

[0] https://lists.freedesktop.org/archives/mesa-dev/2017-September/1709
11.html

> Deprecating and removing it (at a later stage) also a nice option,
> since it will allow us to do some tidy-ups.
> 
> What do you guys think? I'd love to hear people's thoughts about this.
> 
> Thanks
> Emil
> 
> *Fedora, Suse, Arch, Debian, Ubuntu, FreeBSD
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-maintainers/attachments/20171003/04f36598/attachment.sig>