virtual/opencl contains the restriction "abi_x86_64? ( !abi_x86_32?" when it comes to dev-libs/amdgpu-pro-opencl. This is probably a leftover from a time when dev-libs/amdgpu-pro-opencl did not support multilib that is no longer relevant and should be removed.
Unfortunately simply updating virtual/opencl would break things for x86 users because even though dev-libs/amdgpu-pro-opencl supports ABI_X86=32, it is only keyworded ~amd64. I have just requested it to be keyworded ~x86 as well, all is in the hands of x86 arch testers now.
amd64 could still be fixed even if dev-libs/amdgpu-pro-opencl is not keyworded for x86. The current condition: video_cards_amdgpu? ( abi_x86_64? ( !abi_x86_32? ( dev-libs/amdgpu-pro-opencl ) ) ) could be turned into: video_cards_amdgpu? ( abi_x86_64? ( dev-libs/amdgpu-pro-opencl ) ) And finaly when the keyword happens remove the check for abi_x86_64 as well. Of course, it depends on how long do you expect the keywording to take if it makes sense to do it in two steps.
Actually, after checking the dev-libs/amdgpu-pro-opencl ebuilds, all of them have: KEYWORDS="~amd64 ~x86" And it's not a recent change, maybe you were remebering it wrong?
Created attachment 579700 [details] opencl-0-r7.ebuild Okay, on one hand it looks like it might take a while for dev-libs/amdgpu-pro-opencl to get keyworded for x86 and on the other we have got dev-libs/intel-neo as an alternative provider for Intel GPUs. Therefore, I would like to request the following changes to virtual/opencl: 1. Relax ABI constraints on dev-libs/amdgpu-pro-opencl so that amd64 users can take advantage of its recently-added multilib support without exposing it to x86 users; 2. For amd64 users with no need for 32-bit multilib the preferred OpenCL provider is now dev-libs/intel-neo, with dev-libs/beignet still handling ABI_X86_32 both through multilib (Neo compilation with -m32 fails due to conflicting variable types; I have yet to confirm with upstream if they officially support x86 at all). Additionally I would like to suggest moving the Neo/Beignet dependency ahead of the mesa dependency so that at least for the time being they become the preferred providers for Intel. Come to think of it, can one use mesa for OpenCL support on Intel GPUs at all? I know we have FINALLY got a Gallium3D Intel driver available but I have yet to see any mention of it providing compute support.
For future reference: intel-neo does NOT support 32-bit compilation. See https://github.com/intel/compute-runtime/issues/179 .
(In reply to Marek Szuba from comment #4) > Additionally I would like to suggest moving the Neo/Beignet dependency ahead > of the mesa dependency so that at least for the time being they become the > preferred providers for Intel. Come to think of it, can one use mesa for > OpenCL support on Intel GPUs at all? I know we have FINALLY got a Gallium3D > Intel driver available but I have yet to see any mention of it providing > compute support. No, it doesn't provide OpenCL support.
Created attachment 580152 [details] opencl-0-r7.ebuild dev-libs/amdgpu-pro-opencl has just been keyworded ~x86 so it is possible to simplify the relevant condition in virtual/opencl. Attaching an updated ebuild.
(In reply to Marek Szuba from comment #7) > Created attachment 580152 [details] > opencl-0-r7.ebuild I think it's kind of silly for virtuals to have versions with -rX. Just make it virtual/opencl-1 :)
(In reply to Marek Szuba from comment #7) > Created attachment 580152 [details] > opencl-0-r7.ebuild > > dev-libs/amdgpu-pro-opencl has just been keyworded ~x86 so it is possible to > simplify the relevant condition in virtual/opencl. Attaching an updated > ebuild. Are you going to commit this?
(In reply to Matt Turner from comment #9) > Are you going to commit this? I can do it but I would like to be sure that I have got the official blessing of the x11 project to do so, your comment about the version number didn't read like one to me. Otherwise, maintainer timeout can be triggered in a week :-)
(In reply to Marek Szuba from comment #10) > (In reply to Matt Turner from comment #9) > > > Are you going to commit this? > > I can do it but I would like to be sure that I have got the official > blessing of the x11 project to do so, your comment about the version number > didn't read like one to me. Otherwise, maintainer timeout can be triggered > in a week :-) Oh, yeah. Go for it. My /only/ feedback was to just change the version :)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4e61896e4fda690838df18ed03a802b4b0d93b1d commit 4e61896e4fda690838df18ed03a802b4b0d93b1d Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2019-07-10 18:05:44 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2019-07-10 18:07:20 +0000 virtual/opencl: updates for amdgpu and i965 providers Committed with the maintainers' approval. Changes: 1. Remove ABI constraints on dev-libs/amdgpu-pro-opencl - it now both supports amd64 multilib and has been keyworded for x86; 2. For amd64 users with no need for 32-bit multilib the preferred OpenCL provider is now dev-libs/intel-neo - it is more modern and faster, moreover dev-libs/beignet has been deprecated upstream in favour of NEO for systems which support the latter (i.e. native amd64 on Skylake and up); 3. Move the Beignet/NEO dependency ahead of the media-libs/mesa[opencl] dependency - Mesa only provides OpenCL support to Gallium-based drivers and i965 doesn't use Gallium at all. Closes: https://bugs.gentoo.org/686964 Signed-off-by: Marek Szuba <marecki@gentoo.org> Package-Manager: Portage-2.3.66, Repoman-2.3.11 virtual/opencl/opencl-1.ebuild | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
