Gentoo Archives: gentoo-dev

From: Roy Bamford <neddyseagoon@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation
Date: Sun, 17 Jun 2018 12:20:05
Message-Id: oWjCsOpMSOG4Ure0cWsCny@AhYHAqgwON/m8uOongkFs
In Reply to: Re: [gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation by Brian Dolbec
1 On 2018.06.17 08:49, Brian Dolbec wrote:
2 > On Sat, 16 Jun 2018 21:40:10 -0700
3 > Matt Turner <mattst88@g.o> wrote:
4 >
5 > > Hello,
6 > >
7 > > VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and
8 > > some others in media-libs/mesa's VIDEO_CARDS. radeon and intel
9 > > corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has
10 > > meant classic r100, r200, r300, and r600 drivers and gallium r600
11 > and
12 > > radeonsi drivers. VIDEO_CARDS=intel has meant classic i915 and i965
13 > > drivers as well as gallium i915.
14 > >
15 > > I added more-specific VIDEO_CARDS for those separate drivers a few
16 > > years ago, so that users could set VIDEO_CARDS="radeon radeonsi" and
17 > > only get the one radeonsi driver they actually wanted while still
18 > > enabling support for x11-libs/libdrm's radeon support code which is
19 > > used by most of those radeon drivers. Of course some users want this
20 > > control and others don't care at all.
21 > >
22 > > The confusion comes in with "classic" DRI drivers vs Gallium
23 > drivers.
24 > > The Gallium abstraction layer allows a hardware driver to handle
25 > > multiple APIs -- OpenGL, D3D9, OpenCL, video decode APIs, etc. For
26 > > instance, users try to build the classic i965 driver (there is no
27 > > Gallium driver for this hardware) with USE=opencl or USE=vaapi and
28 > > don't understand why they didn't get what they wanted (or
29 > REQUIRED_USE
30 > > prevents them from doing so).
31 > >
32 > > Should of Mesa's USE flags, d3d9, llvm, lm_sensors, opencl, openmax,
33 > > unwind, vaapi, vdpau, xa, and xvmc are Gallium-only. Should I make a
34 > > USE_EXPAND for Gallium-only options to attempt to avoid confusion?
35 > > Another point of confusion: not all Gallium drivers support all of
36 > > these features. For instance only the r600 and radeonsi drivers
37 > > support OpenCL. How to best handle this?
38 > >
39 > > It seems like at one extreme you build an extensive set of
40 > > REQUIRED_USE conditions that force users to micromanage their USE
41 > > flags, or you let them enable all sorts of impossible combinations
42 > and
43 > > deal with the confused bug reports.
44 > >
45 > > I would like to somehow get rid of the 'classic' and 'gallium' USE
46 > > flags entirely, but I'm not totally sure how. Maybe I can enable
47 > them
48 > > dependent on VIDEO_CARDS...
49 > >
50 > > Suggestions welcome.
51 > >
52 >
53 > What about creating a tiny pkg that has all the combinations in a
54 > dictionary and can set the USE and VIDEO_CARDS flags according to the
55 > video card(s) you have.
56 >
57 > This would be along the same lines as the
58 > app-portage/cpuid2cpuflags pkg. Then the pkg is updated as new
59 > drivers
60 > and combinations are changed. Perhaps have it run in pkg_postisnt to
61 > print any irregularities it finds and ewarn they need fixing.
62 >
63 > --
64 > Brian Dolbec <dolsen>
65 >
66 >
67 >
68 >
69
70 That would break for cross compiling. My Raspberry PI has a VC4
71 GPU but I build things on an AMD64 box.
72
73 Any autodetection needs an emergency manual override, even if its
74 hidden behind the I_KNOW_WHAT_I_AM_DOING flag.
75
76 --
77 Regards,
78
79 Roy Bamford
80 (Neddyseagoon) a member of
81 elections
82 gentoo-ops
83 forum-mods