| 1 |
Hello, |
| 2 |
|
| 3 |
I think the time has come to follow the example of CUDA and stop |
| 4 |
supporting ABI_X86_32, both natively and in multilib configurations, in |
| 5 |
virtual/opencl. |
| 6 |
|
| 7 |
|
| 8 |
Let us have a quick look at OpenCL providers currently listed in |
| 9 |
virtual/opencl-2: |
| 10 |
|
| 11 |
1. No 32-bit support: |
| 12 |
|
| 13 |
- dev-libs/intel-neo (Intel GPUs from Broadwell onwards) - upstream has |
| 14 |
confirmed NEO requires a 64-bit system and stated they have no plans to |
| 15 |
add 32-bit support; |
| 16 |
|
| 17 |
- dev-libs/rocm-opencl-runtime (AMD GPUs supported by the amdgpu |
| 18 |
driver) - ROC ebuilds support neither multilib nor native x86, no 32-bit |
| 19 |
binary packages produced by upstream; |
| 20 |
|
| 21 |
- dev-util/intel-ocl-sdk (Intel CPUs) - closed-source, and while there |
| 22 |
*are* 32-bit builds for Windows Intel only supports 64-bit Linux; |
| 23 |
|
| 24 |
|
| 25 |
2. Partial 32-bit support: |
| 26 |
|
| 27 |
- x11-drivers/nvidia-drivers (Nvidia GPUs) - all versions currently |
| 28 |
available in the tree support amd64 multilib but only one of them |
| 29 |
(390.132-r1, which according to the Nvidia Web site only supports legacy |
| 30 |
GPUs) supports both KEYWORDS=x86 and USE=uvm. |
| 31 |
|
| 32 |
3. Do support ABI_X86_32: |
| 33 |
|
| 34 |
- dev-libs/beignet (Intel Sandy Bridge, Ivy Bridge and Haswell GPUs) - |
| 35 |
last-rited due to having been effectively orphaned by upstream and lack |
| 36 |
of official support for LLVM versions newer than 7; |
| 37 |
|
| 38 |
- dev-libs/amdgpu-pro-opencl (AMD Polaris) - proprietary, hacky (it |
| 39 |
basically pulls OpenCL-related parts of the AMDGPU Pro stack in hope |
| 40 |
they will work with the open AMDGPU stack, which is not something AMD |
| 41 |
supports), no longer maintained in Gentoo; |
| 42 |
|
| 43 |
- media-libs/mesa[opencl] (old Radeon and Nvidia GPUs) - the only |
| 44 |
provider without a huge list of caveats, if you both have an old-enough |
| 45 |
GPU and do not mind only being able to use OpenCL 1.1. it actually seems |
| 46 |
to work fine. |
| 47 |
|
| 48 |
|
| 49 |
In other words, nearly every other provider either is or should be |
| 50 |
(ROCm) wrapped in the "abi_x86_64? ( ! abi_x86_32 ( ... ) )" guard. This |
| 51 |
makes virtual/opencl multilib support minimal at best and native-x86 |
| 52 |
support is even more limited. |
| 53 |
|
| 54 |
Do we even want to still bother? Especially the multilib bit, seeing as |
| 55 |
unless there is some super-special proprietary 32-bit OpenCL-aware |
| 56 |
software out there, OpenCL support in Wine seems to be the only thing |
| 57 |
that actually needs it - and I have my doubts regarding the usefulness |
| 58 |
of running OpenCL-aware Windows software under Linux. |
| 59 |
|
| 60 |
What do you think, guys? |
| 61 |
|
| 62 |
Moreover, assuming we do decide to make OpenCL support 64-bit only, what |
| 63 |
do you reckon should be done? Things I have thought of: |
| 64 |
1. News item; |
| 65 |
2. Mask USE=abi_x86_32 in virtual/opencl for all profiles and |
| 66 |
USE=opencl globally for x86 profiles; |
| 67 |
3. At some point later, remove the x86 keyword from virtual/opencl. |
| 68 |
|
| 69 |
|
| 70 |
-- |
| 71 |
Marecki |
Archives