[gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl

[gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 1113 bytes --]


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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl

[Matt Turner]

On Mon, Dec 16, 2019 at 10:26 AM Marek Szuba <marecki@gentoo.org> 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

[Jaco Kroon]

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 <marecki@gentoo.org> 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

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 1571 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]