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. 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
