[gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation

[gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation

[Matt Turner]

Hello,

VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and
some others in media-libs/mesa's VIDEO_CARDS. radeon and intel
corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has
meant classic r100, r200, r300, and r600 drivers and gallium r600 and
radeonsi drivers. VIDEO_CARDS=intel has meant classic i915 and i965
drivers as well as gallium i915.

I added more-specific VIDEO_CARDS for those separate drivers a few
years ago, so that users could set VIDEO_CARDS="radeon radeonsi" and
only get the one radeonsi driver they actually wanted while still
enabling support for x11-libs/libdrm's radeon support code which is
used by most of those radeon drivers. Of course some users want this
control and others don't care at all.

The confusion comes in with "classic" DRI drivers vs Gallium drivers.
The Gallium abstraction layer allows a hardware driver to handle
multiple APIs -- OpenGL, D3D9, OpenCL, video decode APIs, etc. For
instance, users try to build the classic i965 driver (there is no
Gallium driver for this hardware) with USE=opencl or USE=vaapi and
don't understand why they didn't get what they wanted (or REQUIRED_USE
prevents them from doing so).

Should of Mesa's USE flags, d3d9, llvm, lm_sensors, opencl, openmax,
unwind, vaapi, vdpau, xa, and xvmc are Gallium-only. Should I make a
USE_EXPAND for Gallium-only options to attempt to avoid confusion?
Another point of confusion: not all Gallium drivers support all of
these features. For instance only the r600 and radeonsi drivers
support OpenCL. How to best handle this?

It seems like at one extreme you build an extensive set of
REQUIRED_USE conditions that force users to micromanage their USE
flags, or you let them enable all sorts of impossible combinations and
deal with the confused bug reports.

I would like to somehow get rid of the 'classic' and 'gallium' USE
flags entirely, but I'm not totally sure how. Maybe I can enable them
dependent on VIDEO_CARDS...

Suggestions welcome.

Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 3342 bytes --]

On Sat, 16 Jun 2018 21:40:10 -0700
Matt Turner <mattst88@gentoo.org> wrote:

> Hello,
> 
> VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and
> some others in media-libs/mesa's VIDEO_CARDS. radeon and intel
> corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has
> meant classic r100, r200, r300, and r600 drivers and gallium r600 and
> radeonsi drivers. VIDEO_CARDS=intel has meant classic i915 and i965
> drivers as well as gallium i915.
> 
> I added more-specific VIDEO_CARDS for those separate drivers a few
> years ago, so that users could set VIDEO_CARDS="radeon radeonsi" and
> only get the one radeonsi driver they actually wanted while still
> enabling support for x11-libs/libdrm's radeon support code which is
> used by most of those radeon drivers. Of course some users want this
> control and others don't care at all.
> 
> The confusion comes in with "classic" DRI drivers vs Gallium drivers.
> The Gallium abstraction layer allows a hardware driver to handle
> multiple APIs -- OpenGL, D3D9, OpenCL, video decode APIs, etc. For
> instance, users try to build the classic i965 driver (there is no
> Gallium driver for this hardware) with USE=opencl or USE=vaapi and
> don't understand why they didn't get what they wanted (or REQUIRED_USE
> prevents them from doing so).
> 
> Should of Mesa's USE flags, d3d9, llvm, lm_sensors, opencl, openmax,
> unwind, vaapi, vdpau, xa, and xvmc are Gallium-only. Should I make a
> USE_EXPAND for Gallium-only options to attempt to avoid confusion?
> Another point of confusion: not all Gallium drivers support all of
> these features. For instance only the r600 and radeonsi drivers
> support OpenCL. How to best handle this?
> 
> It seems like at one extreme you build an extensive set of
> REQUIRED_USE conditions that force users to micromanage their USE
> flags, or you let them enable all sorts of impossible combinations and
> deal with the confused bug reports.

My simplified understanding of your problem is as follows:

- You have M video cards
- You have N possible features
- But not all M video cards support N features
- One user may want support for 2xM video cards concurrently

And the above combination produces an unmanageable mess.

Is it at all feasible to splice mesa into a main package
and a collection of video-card backends, where USE flags can
be defined card-specifically?

Failing that, I'd consider the possibility of a pkg_pretend phase
that prints a matrix of the video cards support is being built for,
showing the features from those selected that will be supported, for
example:

---

* mesa: not all features are available on all video cards, mesa will
  only build with following video card feature sets:

  nv   : opencl vaapi xvmc
  i965 :              xvmc

  If this is acceptable, please set MESA_MIXED_VIDEO_FEATURES=1 in
  your portage make.conf

---

and then die() when that's not 1.


This:
- gets around needing some obscene REQUIRED_USE mess
- still runs early prior to tree merge
- gives users the convenience they want, while also giving transparency
- gets around the whole "REQUIRED_USE is kinda useless because there's
  no way to document reasons behind various exclusions or suggest
  solution strategies" problem.


   

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

Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation

[Brian Dolbec]

On Sat, 16 Jun 2018 21:40:10 -0700
Matt Turner <mattst88@gentoo.org> wrote:

> Hello,
> 
> VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and
> some others in media-libs/mesa's VIDEO_CARDS. radeon and intel
> corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has
> meant classic r100, r200, r300, and r600 drivers and gallium r600 and
> radeonsi drivers. VIDEO_CARDS=intel has meant classic i915 and i965
> drivers as well as gallium i915.
> 
> I added more-specific VIDEO_CARDS for those separate drivers a few
> years ago, so that users could set VIDEO_CARDS="radeon radeonsi" and
> only get the one radeonsi driver they actually wanted while still
> enabling support for x11-libs/libdrm's radeon support code which is
> used by most of those radeon drivers. Of course some users want this
> control and others don't care at all.
> 
> The confusion comes in with "classic" DRI drivers vs Gallium drivers.
> The Gallium abstraction layer allows a hardware driver to handle
> multiple APIs -- OpenGL, D3D9, OpenCL, video decode APIs, etc. For
> instance, users try to build the classic i965 driver (there is no
> Gallium driver for this hardware) with USE=opencl or USE=vaapi and
> don't understand why they didn't get what they wanted (or REQUIRED_USE
> prevents them from doing so).
> 
> Should of Mesa's USE flags, d3d9, llvm, lm_sensors, opencl, openmax,
> unwind, vaapi, vdpau, xa, and xvmc are Gallium-only. Should I make a
> USE_EXPAND for Gallium-only options to attempt to avoid confusion?
> Another point of confusion: not all Gallium drivers support all of
> these features. For instance only the r600 and radeonsi drivers
> support OpenCL. How to best handle this?
> 
> It seems like at one extreme you build an extensive set of
> REQUIRED_USE conditions that force users to micromanage their USE
> flags, or you let them enable all sorts of impossible combinations and
> deal with the confused bug reports.
> 
> I would like to somehow get rid of the 'classic' and 'gallium' USE
> flags entirely, but I'm not totally sure how. Maybe I can enable them
> dependent on VIDEO_CARDS...
> 
> Suggestions welcome.
> 

What about creating a tiny pkg that has all the combinations in a
dictionary and can set the USE and VIDEO_CARDS flags according to the
video card(s) you have.

This would be along the same lines as the
app-portage/cpuid2cpuflags pkg.  Then the pkg is updated as new drivers
and combinations are changed.  Perhaps have it run in pkg_postisnt to
print any irregularities it finds and ewarn they need fixing.

-- 
Brian Dolbec <dolsen>

[gentoo-dev] Re: Suggestions for simplifying VIDEO_CARDS situation

[Luca Barbato]

On 17/06/2018 06:40, Matt Turner wrote:
> I would like to somehow get rid of the 'classic' and 'gallium' USE
> flags entirely, but I'm not totally sure how. Maybe I can enable them
> dependent on VIDEO_CARDS...

But shouldn't mesa have a software fallback for a good deal of those
features?

Probably some logic to issue a warning might help reduce the report
about confusing combinations w/out being too annoying?

lu

Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 3157 bytes --]

On 2018.06.17 08:49, Brian Dolbec wrote:
> On Sat, 16 Jun 2018 21:40:10 -0700
> Matt Turner <mattst88@gentoo.org> wrote:
> 
> > Hello,
> > 
> > VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and
> > some others in media-libs/mesa's VIDEO_CARDS. radeon and intel
> > corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has
> > meant classic r100, r200, r300, and r600 drivers and gallium r600
> and
> > radeonsi drivers. VIDEO_CARDS=intel has meant classic i915 and i965
> > drivers as well as gallium i915.
> > 
> > I added more-specific VIDEO_CARDS for those separate drivers a few
> > years ago, so that users could set VIDEO_CARDS="radeon radeonsi" and
> > only get the one radeonsi driver they actually wanted while still
> > enabling support for x11-libs/libdrm's radeon support code which is
> > used by most of those radeon drivers. Of course some users want this
> > control and others don't care at all.
> > 
> > The confusion comes in with "classic" DRI drivers vs Gallium
> drivers.
> > The Gallium abstraction layer allows a hardware driver to handle
> > multiple APIs -- OpenGL, D3D9, OpenCL, video decode APIs, etc. For
> > instance, users try to build the classic i965 driver (there is no
> > Gallium driver for this hardware) with USE=opencl or USE=vaapi and
> > don't understand why they didn't get what they wanted (or
> REQUIRED_USE
> > prevents them from doing so).
> > 
> > Should of Mesa's USE flags, d3d9, llvm, lm_sensors, opencl, openmax,
> > unwind, vaapi, vdpau, xa, and xvmc are Gallium-only. Should I make a
> > USE_EXPAND for Gallium-only options to attempt to avoid confusion?
> > Another point of confusion: not all Gallium drivers support all of
> > these features. For instance only the r600 and radeonsi drivers
> > support OpenCL. How to best handle this?
> > 
> > It seems like at one extreme you build an extensive set of
> > REQUIRED_USE conditions that force users to micromanage their USE
> > flags, or you let them enable all sorts of impossible combinations
> and
> > deal with the confused bug reports.
> > 
> > I would like to somehow get rid of the 'classic' and 'gallium' USE
> > flags entirely, but I'm not totally sure how. Maybe I can enable
> them
> > dependent on VIDEO_CARDS...
> > 
> > Suggestions welcome.
> > 
> 
> What about creating a tiny pkg that has all the combinations in a
> dictionary and can set the USE and VIDEO_CARDS flags according to the
> video card(s) you have.
> 
> This would be along the same lines as the
> app-portage/cpuid2cpuflags pkg.  Then the pkg is updated as new
> drivers
> and combinations are changed.  Perhaps have it run in pkg_postisnt to
> print any irregularities it finds and ewarn they need fixing.
> 
> -- 
> Brian Dolbec <dolsen>
> 
> 
> 
> 

That would break for cross compiling.  My Raspberry PI has a VC4
GPU but I build things on an AMD64 box.

Any autodetection needs an emergency manual override, even if its
hidden behind the I_KNOW_WHAT_I_AM_DOING flag.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

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