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

[Kent Fredric]

On Sat, 16 Jun 2018 21:40:10 -0700
Matt Turner <mattst88@g.o> 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.