Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Julien Cristau]

[dropping -devel, adding mesa and kde maintainers instead]

Long ago I heard rumors of development work on mesa that would allow it to
function as a proxy library, so that apps would link against libGL as needed
and the GL implementation would use a hardware-accelerated GLES driver where
possible, falling back to software GL where necessary.

This seems unlikely -- I believe GLES and GL have different semantics in
a few places which makes implementing GL on GLES inefficient; mostly
that GLES is missing stuff that GL applications often use, but I think
there are places where GLES is just different, including in how GLSL
works.

Perhaps that explains why no one ever actually succeeded in implementing it,
then?
Thanks for the context.

I haven't tried, but I would expect that applications could use both GL
and GLES APIs at the same time, even to the same window. If this does
work with Mesa, then linking Qt against GLES wouldn't restrict
applications using free drivers at least?

My recollection is that this becomes a practical problem of applications
that want to use both Qt and GL being unbuildable due to namespace
collisions at build time.

Do you know if there have been attempts at resolving those collisions
upstream (either Qt or mesa / khronos)?

I seem to remember a couple of bug reports against mesa on the Debian
side but am curious about any escalations.

Cheers,
Julien

[Lisandro Damián Nicanor Pérez Meyer]

Post by Julien Cristau
[dropping -devel, adding mesa and kde maintainers instead]

ACK.

Post by Julien Cristau

Long ago I heard rumors of development work on mesa that would allow it to
function as a proxy library, so that apps would link against libGL as
needed and the GL implementation would use a hardware-accelerated GLES
driver where possible, falling back to software GL where necessary.

This seems unlikely -- I believe GLES and GL have different semantics in
a few places which makes implementing GL on GLES inefficient; mostly
that GLES is missing stuff that GL applications often use, but I think
there are places where GLES is just different, including in how GLSL
works.

Perhaps that explains why no one ever actually succeeded in implementing
it, then?
Thanks for the context.

I haven't tried, but I would expect that applications could use both GL
and GLES APIs at the same time, even to the same window. If this does
work with Mesa, then linking Qt against GLES wouldn't restrict
applications using free drivers at least?

My recollection is that this becomes a practical problem of applications
that want to use both Qt and GL being unbuildable due to namespace
collisions at build time.

Do you know if there have been attempts at resolving those collisions
upstream (either Qt or mesa / khronos)?
I seem to remember a couple of bug reports against mesa on the Debian
side but am curious about any escalations.

The only thing I remember that sounds like this is:

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798408>

"[arm] libgles2-mesa-dev and libglew-dev disagree over GLsizeiptr"

But maybe it was something else :-/