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

[Ian Romanick]

On 08/13/2013 07:49 AM, Siarhei Siamashka wrote:
> 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.

What does that have to do with building Mesa without desktop GL?  Build 
Mesa *with* ES, and develop your software.

> 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.

It's ugly once at package-time instead of ugly continuously at 
development time.

>> 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.

This all sounds like a packaging problem.  It should be fixed in the 
packaging, not in the upstream project.

> 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.

You should work with Linaro to get their code upstream.  That sounds 
like an orthogonal issue.