Summary: | virtual/opencl new ebuild for OpenCL providers (nvidia/ati/etc...) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michal Pytasz <mpytasz> |
Component: | New packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | enrico.tagliavini, fcoiffie, jekarlson, m.debruijne, trogdog, vapier, xarthisius |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 257626 | ||
Bug Blocks: | 395521 |
Description
Michal Pytasz
2011-11-27 11:00:18 UTC
the virtual is only half the problem. we have blockers atm between these packages. we'll need an eselect module to handle swapping out implementations, or perhaps integrating opencl with opengl. i've started an virtual/opencl ebuild so people will stop wasting random maintainers times (like imagemagick/wine): http://sources.gentoo.org/virtual/opencl/opencl-0.ebuild?rev=1.1 Note that amd implementation still requires headers for compile time deps AFAIK (eg. AMD-app-sdk https://bugs.gentoo.org/show_bug.cgi?id=257626 - maintainer wanted ) thanks for the heads up. i've dropped ati then for now. http://sources.gentoo.org/virtual/opencl/opencl-0.ebuild?r1=1.1&r2=1.2 The headers are standardized and can be pulled from (http://www.khronos.org/registry/cl/). It may be a good idea to package them separately rather than depend on the vendors to provide them. Maybe even mask the vendor's versions to resolve potential conflicts. Also, slightly related. The opencl use flag is (erroneously?) masked on the hardened profile. I'm attempting to setup an automated scientific computing system on a hardened server. I use both the CPU and GPU (AMD) opencl profiles for processing. (In reply to comment #4) > The headers are standardized and can be pulled from > (http://www.khronos.org/registry/cl/). It may be a good idea to package them > separately rather than depend on the vendors to provide them. Maybe even mask > the vendor's versions to resolve potential conflicts. I've just made several commits that take that into account, see app-admin/eselect-opencl :) > Also, slightly related. The opencl use flag is (erroneously?) masked on the > hardened profile. I'm attempting to setup an automated scientific computing > system on a hardened server. I use both the CPU and GPU (AMD) opencl profiles > for processing. Yeah, that actually stopped me from committing updated version of virtual/opencl I've contacted hardened team so they could look into any issues. *opencl-0-r1 (04 Feb 2012) 04 Feb 2012; Kacper Kowalik <xarthisius@gentoo.org> +opencl-0-r1.ebuild, metadata.xml: Utilize new app-admin/eselect-opencl and the fact that we now have 3 viable providers, use flags are no longer mutually exclusive Thank you for your work... But now there is no dependency anymore to cuda-toolkit on nvidia systems. So a depclean removed it and now wine says when emerging: configure: error: OpenCL development files not found, OpenCL won't be supported. Perhaps nvidia-drivers should depend on cuda-toolkit when opencl USE flag is set? But ati-drivers doesn't have that USE flag too. I see this bug is set to resolved fixed. Should I file this as a new bug? (In reply to comment #7) > Thank you for your work... > But now there is no dependency anymore to cuda-toolkit on nvidia systems. That's intended, x11-drivers/nvidia-drivers are enough to get working OpenCL. > So a depclean removed it and now wine says when emerging: > > configure: error: OpenCL development files not found, OpenCL won't be > supported. > > Perhaps nvidia-drivers should depend on cuda-toolkit when opencl USE flag is > set? > But ati-drivers doesn't have that USE flag too. > > I see this bug is set to resolved fixed. Should I file this as a new bug? I guess you've been hit by a bug 402407. Try running: eselect opencl set nvidia, latest version of ebuild already has it. Mea culpa... (In reply to comment #8) > (In reply to comment #7) > > Thank you for your work... > > But now there is no dependency anymore to cuda-toolkit on nvidia systems. > That's intended, x11-drivers/nvidia-drivers are enough to get working OpenCL. > > So a depclean removed it and now wine says when emerging: > > > > configure: error: OpenCL development files not found, OpenCL won't be > > supported. > > > > Perhaps nvidia-drivers should depend on cuda-toolkit when opencl USE flag is > > set? > > But ati-drivers doesn't have that USE flag too. > > > > I see this bug is set to resolved fixed. Should I file this as a new bug? > > I guess you've been hit by a bug 402407. Try running: eselect opencl set > nvidia, latest version of ebuild already has it. Mea culpa... It was more my fail. I was using my own overlay nvidia-drivers-295.17.ebuild that was based on the 290.10 ebuild. So I didn't see the new one. Now I took the 290.10-r1 as my source and all is fine. Thanks |