1 |
On Mon, Jul 23, 2018 at 10:11 AM, Mart Raudsepp <leio@g.o> wrote: |
2 |
> Hello, |
3 |
> |
4 |
> Currently we have rather a mess in terms of OpenGL API handling. |
5 |
> I think much of it comes from USE=opengl being rather vague - is it |
6 |
> supposed to mean "Use desktop GL", "Use GLX", or "Enable OpenGL |
7 |
> support". All of these mean quite different things: |
8 |
> * desktop GL means full OpenGL API, which in turn can be either used |
9 |
> via GLX platform (X11 only) or EGL platform. |
10 |
> * GLX means GLX platform - usable only on X11; all good and same as |
11 |
> desktop GL in the past, but we have people wanting wayland-only now |
12 |
> (and YES, desktop GL via EGL platform _is_ a thing), and GLX obviously |
13 |
> isn't something that works in native wayland. |
14 |
> * GL support could mean 3D via OpenGL in general; be it OpenGL, GLESv2, |
15 |
> GLESv3... |
16 |
> |
17 |
> To make things easier to follow, there are basically three different |
18 |
> concepts and potential choices to make: |
19 |
> |
20 |
> * API |
21 |
> * Platform |
22 |
> * Windowing system |
23 |
> |
24 |
> API is either "full desktop" OpenGL (think e.g. OpenGL 4.5), or GLES; |
25 |
> GLES has multiple versions, but in practice it's GLESv2 with optional |
26 |
> support for GLESv3 - however afaik latest mesa supports GLESv3 too |
27 |
> whenever GLESv2 is built. |
28 |
> |
29 |
> Platform is either GLX or EGL. GLX only works in combination with "full |
30 |
> desktop" OpenGL; EGL can work with either. |
31 |
> For non-Linux there's also CGL (OSX), WGL (Windows), EAGL (iOS) and |
32 |
> more. Can be interesting for Gentoo Prefix. |
33 |
> |
34 |
> "EGL is an interface between Khronos rendering APIs such as OpenGL ES |
35 |
> or OpenVG and the underlying native platform window system." - thus the |
36 |
> third choice with EGL platform - windowing system. This then is about |
37 |
> supporting a certain graphics environment with EGL (with GLX that can |
38 |
> be taken as just always X). |
39 |
> This can be for example x11, wayland, GBM (think rendering 3D directly |
40 |
> on top of a KMS terminal), win32, cocoa, android, vivante framebuffer |
41 |
> (with proprietary vivante 3D stack; not applicable to open source |
42 |
> etnaviv), DispmanX (RPi), etc. |
43 |
> This can be a choice especially for certain kind of OpenGL libraries; |
44 |
> one big example I know of is GStreamer GL libraries. |
45 |
> |
46 |
> |
47 |
> |
48 |
> Anyhow, here's an initial proposal to try to sort it out via a USE=gles |
49 |
> global USE flag and a set of guidelines how to use it together with a |
50 |
> USE=opengl and other related USE flags in ebuilds: |
51 |
> |
52 |
> |
53 |
> use.desc: |
54 |
> opengl - Add support for desktop OpenGL (3D graphics) |
55 |
> gles - Add support for OpenGL ES, or prefer it over desktop OpenGL. This should usually only be enabled globally on embedded systems that do not support full desktop GL. |
56 |
> |
57 |
> [How is it correct to refer to "full desktop" GL without it being |
58 |
> confusing with OpenGL in general?] |
59 |
|
60 |
That's what people on my team call it to differentiate. "Desktop" vs ES. |
61 |
|
62 |
> Guidelines: |
63 |
> |
64 |
> * If package has optional GL support in general (can work with either |
65 |
> desktop GL or GLES when OpenGL is enabled; doesn't care which one is |
66 |
> there), use both opengl and gles in IUSE and enable GL support and |
67 |
> ebuild logic when either is enabled |
68 |
|
69 |
Sounds good. |
70 |
|
71 |
> * If package is fully about OpenGL (GL itself isn't optional) and |
72 |
> supports either desktop GL or GLES, but not both at once: IUSE="gles" |
73 |
> and use GLES if that is set, "full desktop" GL otherwise. |
74 |
|
75 |
Probably the best thing to do. |
76 |
|
77 |
> * If package is fully about OpenGL (GL itself isn't optional) and |
78 |
> supports either desktop GL or GLES, including both at once: IUSE="gles |
79 |
> +opengl" and use whichever is enabled. As GL isn't optional as a whole, |
80 |
> require at least one of them: REQUIRED_USE="|| ( gles opengl )". |
81 |
|
82 |
Sounds good. |
83 |
|
84 |
> * If package has optional OpenGL support and needs specific logic for |
85 |
> the chosen API: IUSE="gles opengl" or IUSE="gles +opengl", depending if |
86 |
> GL should be default enabled (albeit we might want to revise this via |
87 |
> profile level defaults flag instead?) - don't default enable gles, as |
88 |
> it's not a common use case and such embedded system users will have it |
89 |
> globally enabled anyways. |
90 |
> ** Enable any of the GL logic only if either gles or opengl is enabled. |
91 |
> ** If both are supported at the same time, enable whichever is chosen |
92 |
> by user (this could often mean also passing a generic --enable-gl |
93 |
> passing if either USE is set and then specifying the API to use with a |
94 |
> separate build flag). |
95 |
> ** If both are not supported at the same time, set REQUIRED_USE="gles? |
96 |
> ( !opengl )", use whichever is chosen (keeping in mind that both might |
97 |
> be disabled → no GL at all). |
98 |
> |
99 |
> * If package needs to provide choices for the used GL platform or |
100 |
> windowing system, while GL itself is optional as a whole, don't forget |
101 |
> to keep the dependencies and other logic for the platform/WS |
102 |
> conditional to USE=gles and/or USE=opengl. This is usually easiest to |
103 |
> handle via GL_DEPS helper variable with dependencies applicable to |
104 |
> either and then putting it in as e.g. "opengl? ( $GL_DEPS ) gles? ( |
105 |
> $GL_DEPS )" together with any specific ones; similar for certain needed |
106 |
> REQUIRED_USEs, with appropriate conditional blocks in src_configure(). |
107 |
> |
108 |
> * If package supports X11 via either GLX or EGL x11 windowing system, |
109 |
> just enable GLX via USE="opengl X" (or USE="-gles X" if no opengl in |
110 |
> IUSE) and EGL x11 via USE="egl X". Don't forget that "egl X" should |
111 |
> pull in EGL and X dependencies necessary for it only if GL as a whole |
112 |
> is enabled, if that is optional. |
113 |
|
114 |
Sounds good. |
115 |
|
116 |
> * It is OK to have certain REQUIRED_USE restrictions when applicable, |
117 |
> but avoid unnecessary pain via appropriate use of IUSE defaults. Also |
118 |
> don't forget that some restrictions might only apply if GL as a whole |
119 |
> is enabled — e.g. REQUIRED_USE="gles? ( $GL_REQUIRED_USE ) opengl? ( |
120 |
> $GL_REQUIRED_USE )". Don't force users to make choices when that choice |
121 |
> isn't even relevant — e.g. REQUIRED_USE="wayland? ( egl )", when this |
122 |
> is only relevant if optional GL is enable via either USE="opengl" or |
123 |
> USE="gles" - user would have to potentially enable egl without reason, |
124 |
> because he wanted non-GL wayland support for the package, but wayland |
125 |
> windowing system support isn't built anyways (just generic wayland |
126 |
> support). |
127 |
> |
128 |
> ---- |
129 |
> |
130 |
> Initially I thought of a global USE=gles2, but during the writing of |
131 |
> this e-mail, I realized that as USE=opengl doesn't specify a version |
132 |
> either (e.g. 3.3 or 4.5), so combined with gles3 not really needing a |
133 |
> separate handling, it'd be more consistent with just USE=gles. |
134 |
> However I'm rather torn on this - it could just as well be USE=gles2 |
135 |
> instead, which just specifies that it's GLESv2 or later; then it's also |
136 |
> clear we don't deal with old GLESv1 via this. |
137 |
|
138 |
gles2 is much more common than just gles in the tree. There are no |
139 |
known gles1 applications on desktop Linux, so I'm happy to just remove |
140 |
the gles1 flag from media-libs/mesa. |
141 |
|
142 |
I'd say we go with gles2. |
143 |
|
144 |
> I doubt this proposal is perfect, but I think it does bring a bit of |
145 |
> sanity and consistency to the situation. Additionally I only have a |
146 |
> view of what my co-maintained packages are doing, support and need; I |
147 |
> might not have thought of valid setups needed by other packages, which |
148 |
> this wouldn't work for. |
149 |
> |
150 |
> I also realize this can be complex to handle by maintainers in ebuilds, |
151 |
> but the goal is to have it consistent and understandable to users, and |
152 |
> easier to handle via global USE choice: |
153 |
> "If you want to enable OpenGL when it's a choice → enable USE=opengl or |
154 |
> USE=gles globally, depending if you have full desktop OpenGL support or |
155 |
> not (embedded)". |
156 |
> |
157 |
> For ebuild complexity, it's not all that bad; see for example media- |
158 |
> libs/gst-plugins-base-1.14.1 or newer. |
159 |
> |
160 |
> |
161 |
> I'm happy to hear valid concerns where this wouldn't work or situations |
162 |
> where this isn't good for global choosing by user. But please be |
163 |
> considerate and bring up only new cases, not those that are already |
164 |
> brought up on the thread (that is, read all unread mails in thread |
165 |
> before posting yourself). |
166 |
|
167 |
Thanks for starting this thread (and for removing the REQUIRED_USE from gst :) |