On Sat, 16 Jun 2018 21:40:10 -0700 Matt Turner <matts...@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.
pgpTeZ8tbFxgk.pgp
Description: OpenPGP digital signature
