From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 5576A138334 for ; Sun, 17 Jun 2018 06:29:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CC1C5E08A2; Sun, 17 Jun 2018 06:29:08 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 215CEE0894 for ; Sun, 17 Jun 2018 06:29:07 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id DAB07335C7E for ; Sun, 17 Jun 2018 06:29:04 +0000 (UTC) Date: Sun, 17 Jun 2018 18:28:39 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation Message-ID: <20180617182839.4694f910@katipo2.lan> In-Reply-To: References: Organization: Gentoo X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/RWyN6+5XgNuVij2gJuDb7Uu"; protocol="application/pgp-signature" X-Archives-Salt: 0cbf9b62-22a0-422f-877d-9b3d57e065a6 X-Archives-Hash: bebbcd75472176a3570c6a01c4887c1c --Sig_/RWyN6+5XgNuVij2gJuDb7Uu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 16 Jun 2018 21:40:10 -0700 Matt Turner wrote: > Hello, >=20 > 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=3Dradeon has > meant classic r100, r200, r300, and r600 drivers and gallium r600 and > radeonsi drivers. VIDEO_CARDS=3Dintel has meant classic i915 and i965 > drivers as well as gallium i915. >=20 > I added more-specific VIDEO_CARDS for those separate drivers a few > years ago, so that users could set VIDEO_CARDS=3D"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. >=20 > 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=3Dopencl or USE=3Dvaapi and > don't understand why they didn't get what they wanted (or REQUIRED_USE > prevents them from doing so). >=20 > 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? >=20 > 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=3D1 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. =20 --Sig_/RWyN6+5XgNuVij2gJuDb7Uu Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPZazbI/qrFT1o9rn6FQySxNmqCAFAlsl/6YACgkQ6FQySxNm qCCXwBAAtMebsTUlntxyJZSbLE0TP0bjnjU3eRQdgyL4XKv557PUB9b4HZHN6eYa yKnEvKTzST1JYp4Q+ugI/EqMbKhJ5bYu8w02gLC3Gi7pbkSDrwqwJ7BdFnUucn40 15KPf/t4jyJw2G6f84dgUkmFex8B+RdZZbE5jiP/ej85vYax0QlTgH7so+6yuZn0 4d/zUeNLFWoJuKRdKYkFEy00tGqZKg6EY8QxA0xnxNYTLqlCYC2RN+H267zUKRkE 72U46L/PO55IzFsczrE1qtlibkDhmu9+beeULqawVBLhRDLUu3oZUbg3VMjlnD8u VQ/wPoF7R77PQ8nOJI9wCA+hqw8ZpUR9nrzxttoBYF8FTfh2E1UikvaF5L0+og5y ZSM7mPdo5aZswf85/VA1tXOWf+X7sOPQwIgZyTFVpyg9flDoo0h/IuLI7XpogVBX q3wOQaqkI4irb10eku2WkHbq13yZXgUyzL2sklRqizx2Evf9Z15NGSwuXeMS40WT DR6T0mjXZ6L7x/Yzj5xcmLEDBQsdvl0XK/Zv9wE1JQN8b0N2k3oM++o0TPs+u9eq qzAVWUiS7MDIHOgGyWe9I35+XVMVxtQofpA7ufJeKLm/0kELQ8v370/RN7Uvbt1S osK381OPGJE9Q17AcWXovizdVhFkikYkwE3g9esnWRl0kS8Pm4I= =YVBA -----END PGP SIGNATURE----- --Sig_/RWyN6+5XgNuVij2gJuDb7Uu--