Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl
On 2019-12-17 21:21, Matt Turner wrote: >> What do you think, guys? > > I don't love it. > > I don't like the mess that has become VIDEO_CARDS=... either. radeon > vs radeonsi vs amdgpu. [...] I hear you and very much agree, especially regarding the Radeon mess. That said, it seems what we are complaining about is the whole VIDEO_CARDS system rather than the introduction of 'iris' into virtual/opencl. The current situation with OpenCL providers for Intel GPUs ugly even disregarding the above. Basically, it is: 1. Set VIDEO_CARDS: i965 2a. If you do not set ABI_X86: 32 for virtual/opencl, it will pull in dev-libs/intel-neo 2a.1. NEO may or may not work but with the former more likely than the latter (it's been a few years since Broadwell architecture came out); 2b. If, however, you DO enable 32-bit x86 ABI it will pull dev-libs/beignet instead 2b.1. Beignet at least for the time being is likely to work even on modern systems but nowhere nearly as well as NEO would and without official upstream support. In contrast, reassigning NEO to video_cards_iris would make the Intel-GPU provider tree much more straightforward: 1. For i965, you would get dev-libs/beignet regardless of whether you want 32-bit x86 ABI or not; 2. For iris, you would get dev-libs/intel-neo for native 64 bits and nothing (okay, technically it would fall back to media-libs/mesa - but the fact Mesa is considered a fallback OpenCL provider for all GPUs is a completely different can of worms) for 32-bit x86 ABI. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl
Hi, As someone with a Radeon / Intel hybrid/dual graphics chip. I can only emphasise what Matt says below. It's a PITA currently. Having said that ... I don't see how this can be made simpler, unless we have a tool of sorts that when run on *any* hardware gives you what this needs to be set to, or unconditionally install all possible drivers (something I'd prefer to avoid completely). Kind Regards, Jaco On 2019/12/17 23:21, Matt Turner wrote: > On Mon, Dec 16, 2019 at 10:26 AM Marek Szuba wrote: >> What do you think, guys? > I don't love it. > > I don't like the mess that has become VIDEO_CARDS=... either. radeon > vs radeonsi vs amdgpu. Different names for different bits of the > stack, even for the same hardware. I would like to come up with > something that avoids the confusion users often have. > > Does anyone have suggestions? > > Should we make a cpuid2cpuflags equivalent for VIDEO_CARDS? > > Should VIDEO_CARDS specify only the vendor with MESA_VIDEO_CARDS=... > etc for individual packages? (Seems gross) > > Should VIDEO_CARDS be more fine grained with multiple names for the > same thing sometimes? (e.g., offer VIDEO_CARDS=amdgpu for > media-libs/mesa that enables the radeonsi driver; similarly offer > VIDEO_CARDS=radeonsi for x11-libs/libdrm that enables libdrm_radeon). > > I think perhaps that in conjunction with a cpuid2cpuflags-equivalent > is the most sensible. >
Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl
On Mon, Dec 16, 2019 at 10:26 AM Marek Szuba wrote: > What do you think, guys? I don't love it. I don't like the mess that has become VIDEO_CARDS=... either. radeon vs radeonsi vs amdgpu. Different names for different bits of the stack, even for the same hardware. I would like to come up with something that avoids the confusion users often have. Does anyone have suggestions? Should we make a cpuid2cpuflags equivalent for VIDEO_CARDS? Should VIDEO_CARDS specify only the vendor with MESA_VIDEO_CARDS=... etc for individual packages? (Seems gross) Should VIDEO_CARDS be more fine grained with multiple names for the same thing sometimes? (e.g., offer VIDEO_CARDS=amdgpu for media-libs/mesa that enables the radeonsi driver; similarly offer VIDEO_CARDS=radeonsi for x11-libs/libdrm that enables libdrm_radeon). I think perhaps that in conjunction with a cpuid2cpuflags-equivalent is the most sensible.
[gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl
Penny for your thoughts, guys: I am thinking about splitting the video_cards_i965 condition in virtual/opencl so that NEO is pulled in by video_cards_iris instead, and I wonder if there is anything I haven't thought about. The reason why I would like to do this is that there is clear correspondence between compatibility matrices of the Iris OpenGL driver and the NEO OpenCL driver - both only work on Broadwell and newer. There are differences of course, most notably that the old OpenCL driver (Beignet) is already considered deprecated for systems supported by NEO whereas the old OpenGL driver in Mesa (i965) is still the official one even for newer systems. Nb. to the best of my knowledge it is safe to set VIDEO_CARDS=iris even globally because if both i965 and iris are available, Mesa for now still prefers the former unless the environment variable MESA_LOADER_DRIVER_OVERRIDE has been set to 'iris'. There would of course have to be a news item advising the users of virtual/opencl + dev-libs/intel-neo to adjust their USE flags. What do you think, guys? -- Marecki signature.asc Description: OpenPGP digital signature
