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