[Mesa-dev] OpenGL ES only configuration (without "desktop" OpenGL support)

[Siarhei Siamashka]

On Thu, 08 Aug 2013 16:19:28 -0700
Ian Romanick <idr at freedesktop.org> wrote:

> On 08/06/2013 02:13 PM, Siarhei Siamashka wrote:
> > Hello,
> >
> > Some months ago, the commit "configure.ac: Allow OpenGL ES1 and ES2 only
> > with enabled OpenGL" dropped support for the OpenGL-free configuration.
> >
> >      http://lists.freedesktop.org/archives/mesa-dev/2013-February/033909.html
> >      http://lists.freedesktop.org/archives/mesa-commit/2013-February/041708.html
> >
> > Could this be possibly reverted to allow me to continue "shooting
> > myself in the foot"? The support for OpenGL ES is pretty horrible
> > in the open source software. One nice exception is Qt5 which is doing
> > pretty well. But the rest of the software does not generally work out
> > of the box without patches or tweaks. You can also hardly find a
> > problem-free OpenGL ES compatible open source game (other than Quake3).
> >
> > I have an open feature request for Gentoo, which is a very configurable
> > Linux distribution and should not have any troubles working either with
> > or without OpenGL (the choice is up to the user):
> >
> >      https://bugs.gentoo.org/show_bug.cgi?id=476524
> >
> > But if upstream Mesa treats this configuration as unsupported, then I
> > also don't see it progressing anywhere in Gentoo. So could you please
> > re-consider this decision?
> 
> We've removed all of the #ifdef code inside Mesa that would have made 
> any difference.  It was a nightmare to maintain, and we almost always 
> got it wrong... because nobody was testing that configuration.

I believe this can be changed :-) That's a bit of a chicken/egg problem.
The OpenGL ES support in free software applications and libraries is
so broken, that it's currently a big pain to try this configuration for
anything practical. And the applications/libraries can't be fixed
without having a non-OpenGL environment for development and testing.

The needed tweaks for Mesa are really trivial. Maybe one could also
just compile everything, but delete GL headers, gl.pc and libGL.so
after compilation and before installing Mesa to the system. Still it
is a bit ugly to have the configure script claim that OpenGL ES is not
supported without OpenGL, while in fact it works.

> The only thing this is possibly going to gain you is a trivial amount
> of build time (by not building libGL, etc.).

The compilation time is irrelevant. But it is very useful to be able to
install Mesa without OpenGL headers and without libGL.so, so that the
problematic software just fails at compile time instead of exhibiting
hard to debug problems at runtime.

It seems to be a rather common failure scenario when some big bloatware
application loads both libGL.so (provided by Mesa) and libGLESv2.so
(provided by some proprietary OpenGL ES driver on ARM hardware) into
the same process via indirect library dependencies. These shared
libraries are providing overlapping function names, but are backed by
totally different implementations. And everything blows up as a result
when the application is run, or maybe it even mostly works if you are
lucky.

What's the point installing both Mesa and the proprietary OpenGL ES
drivers on the same system? I would surely love to have open source
hardware accelerated OpenGL ES drivers on ARM systems today. But they
are not quite here yet. And even assuming that we get perfectly
functional free software OpenGL ES drivers for embedded hardware,
the current buggy applications are not going be magically fixed
themselves. Somebody still needs to debug and fix the OpenGL ES
compatibility problems.

The easiest way forward seems to be just allowing to compile Mesa
without desktop OpenGL. It is going to provide:
1. On x86 desktop systems - the development environment for testing
OpenGL ES applications.
2. On ARM hardware via softpipe/llvmpipe - some reference fallback
implementation.
3. Have both the existing proprietary drivers and Mesa installed on
ARM hardware (with the ability to switch between them at any time) -
the applications can run at full speed and be profiled/benchmarked.

Somebody may argue that I'm exaggerating and OpenGL ES support seems
to be not so bad. There were many OpenGL ES related news and
announcements. Also there exists Linaro/Ubuntu distribution and some
videos on youtube showing how it successfully runs something in 3D on
ARM. Still the problem is that in many applications the said OpenGL ES
support is either in the work-in-progress state, or it possibly has
been contributed by somebody some time ago and has already bitrotten.
Also Linaro bundles a bunch of OpenGL ES hacks, which don't seem to be
actively pushed upstream. This all is less than perfect and needs to be
improved. That is unless we are happy with having OpenGL ES just
exclusively for running Qt5 and a few compliant compositing window
managers.

-- 
Best regards,
Siarhei Siamashka