[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] RFC: Removing ABI_X86_32 support from virtual/opencl
From:       Marek Szuba <marecki () gentoo ! org>
Date:       2020-02-28 13:02:06
Message-ID: 77d2fe42-4978-2e78-567e-af97010dcfd0 () gentoo ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


Hello,

I think the time has come to follow the example of CUDA and stop
supporting ABI_X86_32, both natively and in multilib configurations, in
virtual/opencl.


Let us have a quick look at OpenCL providers currently listed in
virtual/opencl-2:

1. No 32-bit support:

 - dev-libs/intel-neo (Intel GPUs from Broadwell onwards) - upstream has
confirmed NEO requires a 64-bit system and stated they have no plans to
add 32-bit support;

 - dev-libs/rocm-opencl-runtime (AMD GPUs supported by the amdgpu
driver) - ROC ebuilds support neither multilib nor native x86, no 32-bit
binary packages produced by upstream;

 - dev-util/intel-ocl-sdk (Intel CPUs) - closed-source, and while there
*are* 32-bit builds for Windows Intel only supports 64-bit Linux;


2. Partial 32-bit support:

 - x11-drivers/nvidia-drivers (Nvidia GPUs) - all versions currently
available in the tree support amd64 multilib but only one of them
(390.132-r1, which according to the Nvidia Web site only supports legacy
GPUs) supports both KEYWORDS=x86 and USE=uvm.

3. Do support ABI_X86_32:

 - dev-libs/beignet (Intel Sandy Bridge, Ivy Bridge and Haswell GPUs) -
last-rited due to having been effectively orphaned by upstream and lack
of official support for LLVM versions newer than 7;

 - dev-libs/amdgpu-pro-opencl (AMD Polaris) - proprietary, hacky (it
basically pulls OpenCL-related parts of the AMDGPU Pro stack in hope
they will work with the open AMDGPU stack, which is not something AMD
supports), no longer maintained in Gentoo;

 - media-libs/mesa[opencl] (old Radeon and Nvidia GPUs) - the only
provider without a huge list of caveats, if you both have an old-enough
GPU and do not mind only being able to use OpenCL 1.1. it actually seems
to work fine.


In other words, nearly every other provider either is or should be
(ROCm) wrapped in the "abi_x86_64? ( ! abi_x86_32 ( ... ) )" guard. This
makes virtual/opencl multilib support minimal at best and native-x86
support is even more limited.

Do we even want to still bother? Especially the multilib bit, seeing as
unless there is some super-special proprietary 32-bit OpenCL-aware
software out there, OpenCL support in Wine seems to be the only thing
that actually needs it - and I have my doubts regarding the usefulness
of running OpenCL-aware Windows software under Linux.

What do you think, guys?

Moreover, assuming we do decide to make OpenCL support 64-bit only, what
do you reckon should be done? Things I have thought of:
 1. News item;
 2. Mask USE=abi_x86_32 in virtual/opencl for all profiles and
USE=opencl globally for x86 profiles;
 3. At some point later, remove the x86 keyword from virtual/opencl.


-- 
Marecki


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]