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 |