On 08/13/2013 07:49 AM, Siarhei Siamashka wrote:
On Thu, 08 Aug 2013 16:19:28 -0700
Ian Romanick <i...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
