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 B4031138334 for ; Sun, 17 Jun 2018 07:51:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 41DB0E08D9; Sun, 17 Jun 2018 07:51:21 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 D08A9E0882 for ; Sun, 17 Jun 2018 07:51:20 +0000 (UTC) Received: from professor-x (d108-172-194-6.bchsia.telus.net [108.172.194.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dolsen) by smtp.gentoo.org (Postfix) with ESMTPSA id 2AB6B335C8A for ; Sun, 17 Jun 2018 07:51:19 +0000 (UTC) Date: Sun, 17 Jun 2018 00:49:31 -0700 From: Brian Dolbec To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation Message-ID: <20180617004931.6c410dcc@professor-x> In-Reply-To: References: X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 7e587ef6-af9e-473f-95dc-b6e659203403 X-Archives-Hash: 4a3cb4610212f0a9a08eefe5030b1486 On Sat, 16 Jun 2018 21:40:10 -0700 Matt Turner 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