On Mon, Jul 23, 2018 at 10:11 AM, Mart Raudsepp wrote:
> Hello,
>
> Currently we have rather a mess in terms of OpenGL API handling.
> I think much of it comes from USE=opengl being rather vague - is it
> supposed to mean "Use desktop GL", "Use GLX", or "Enable OpenGL
> support". All of these mean quite different things:
> * desktop GL means full OpenGL API, which in turn can be either used
> via GLX platform (X11 only) or EGL platform.
> * GLX means GLX platform - usable only on X11; all good and same as
> desktop GL in the past, but we have people wanting wayland-only now
> (and YES, desktop GL via EGL platform _is_ a thing), and GLX obviously
> isn't something that works in native wayland.
> * GL support could mean 3D via OpenGL in general; be it OpenGL, GLESv2,
> GLESv3...
>
> To make things easier to follow, there are basically three different
> concepts and potential choices to make:
>
> * API
> * Platform
> * Windowing system
>
> API is either "full desktop" OpenGL (think e.g. OpenGL 4.5), or GLES;
> GLES has multiple versions, but in practice it's GLESv2 with optional
> support for GLESv3 - however afaik latest mesa supports GLESv3 too
> whenever GLESv2 is built.
>
> Platform is either GLX or EGL. GLX only works in combination with "full
> desktop" OpenGL; EGL can work with either.
> For non-Linux there's also CGL (OSX), WGL (Windows), EAGL (iOS) and
> more. Can be interesting for Gentoo Prefix.
>
> "EGL is an interface between Khronos rendering APIs such as OpenGL ES
> or OpenVG and the underlying native platform window system." - thus the
> third choice with EGL platform - windowing system. This then is about
> supporting a certain graphics environment with EGL (with GLX that can
> be taken as just always X).
> This can be for example x11, wayland, GBM (think rendering 3D directly
> on top of a KMS terminal), win32, cocoa, android, vivante framebuffer
> (with proprietary vivante 3D stack; not applicable to open source
> etnaviv), DispmanX (RPi), etc.
> This can be a choice especially for certain kind of OpenGL libraries;
> one big example I know of is GStreamer GL libraries.
>
>
>
> Anyhow, here's an initial proposal to try to sort it out via a USE=gles
> global USE flag and a set of guidelines how to use it together with a
> USE=opengl and other related USE flags in ebuilds:
>
>
> use.desc:
> opengl - Add support for desktop OpenGL (3D graphics)
> 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.
>
> [How is it correct to refer to "full desktop" GL without it being
> confusing with OpenGL in general?]
That's what people on my team call it to differentiate. "Desktop" vs ES.
> Guidelines:
>
> * If package has optional GL support in general (can work with either
> desktop GL or GLES when OpenGL is enabled; doesn't care which one is
> there), use both opengl and gles in IUSE and enable GL support and
> ebuild logic when either is enabled
Sounds good.
> * If package is fully about OpenGL (GL itself isn't optional) and
> supports either desktop GL or GLES, but not both at once: IUSE="gles"
> and use GLES if that is set, "full desktop" GL otherwise.
Probably the best thing to do.
> * If package is fully about OpenGL (GL itself isn't optional) and
> supports either desktop GL or GLES, including both at once: IUSE="gles
> +opengl" and use whichever is enabled. As GL isn't optional as a whole,
> require at least one of them: REQUIRED_USE="|| ( gles opengl )".
Sounds good.
> * If package has optional OpenGL support and needs specific logic for
> the chosen API: IUSE="gles opengl" or IUSE="gles +opengl", depending if
> GL should be default enabled (albeit we might want to revise this via
> profile level defaults flag instead?) - don't default enable gles, as
> it's not a common use case and such embedded system users will have it
> globally enabled anyways.
> ** Enable any of the GL logic only if either gles or opengl is enabled.
> ** If both are supported at the same time, enable whichever is chosen
> by user (this could often mean also passing a generic --enable-gl
> passing if either USE is set and then specifying the API to use with a
> separate build flag).
> ** If both are not supported at the same time, set REQUIRED_USE="gles?
> ( !opengl )", use whichever is chosen (keeping in mind that both might
> be disabled → no GL at all).
>
> * If package needs to provide choices for the used GL platform or
> windowing system, while GL itself is optional as a whole, don't forget
> to keep the dependencies and other logic for the platform/WS
> conditional to USE=gles and/or USE=opengl. This is usually easiest to
> handle via GL_DEPS helper variable with dependencies applicable to
> either and then putting it in as e.g. "opengl? ( $GL_DEPS ) gles? (
> $GL_DEPS )" together with any specific ones; similar for certain needed
> REQUIRED_USEs, with appropriate conditional blocks in
