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 EB9C0138334 for ; Sun, 17 Jun 2018 04:40:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 16291E08A2; Sun, 17 Jun 2018 04:40:34 +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 839E7E0827 for ; Sun, 17 Jun 2018 04:40:33 +0000 (UTC) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mattst88) by smtp.gentoo.org (Postfix) with ESMTPSA id 16AC1335C8A for ; Sun, 17 Jun 2018 04:40:32 +0000 (UTC) Received: by mail-it0-f44.google.com with SMTP id 76-v6so7808697itx.4 for ; Sat, 16 Jun 2018 21:40:32 -0700 (PDT) X-Gm-Message-State: APt69E3nJscq3idZ03ILD9V0xCj9sYM0Pw5Xuesa7+mBf75oWHlvoauJ LfJoRv4uWu4ZNABIIOsm4+edf4SqI7vXeRKzFEo= X-Google-Smtp-Source: ADUXVKK2H3LhsEGhWtohFTflazS81NHeJ1w4mPL3dkIJpzFaqpGF6jOLh8Rz6oJfDuq5huJmyI6lvOdukNkNVKtEBe4= X-Received: by 2002:a24:6c8c:: with SMTP id w134-v6mr6326166itb.75.1529210430164; Sat, 16 Jun 2018 21:40:30 -0700 (PDT) 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 From: Matt Turner Date: Sat, 16 Jun 2018 21:40:10 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation To: gentoo development Cc: x11 Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: c2a0c238-6ec2-4d5d-8bed-61c2a43e55a3 X-Archives-Hash: b10bacd4836fba1efde261c8c471b6a3 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.