OpenGL to OpenGL ES change on arm64?

Steve Langasek steve.langasek at
Sat Jun 4 00:48:17 UTC 2016

On Sat, Jun 04, 2016 at 02:00:04AM +0200, Matthias Klose wrote:
> > There are two ways to make a GLES-enabled Qt stack available on arm64; the
> > armhf way (build Qt exclusively for GLES), or the x86 way (build alternative
> > stacks for both GL and GLES).

> > Which we should pursue depends on whether there is a use case for OpenGL Qt
> > software anywhere on ARM64.

> > For the phone / embedded GPU case, we have no known chips providing
> > accelerated OpenGL drivers.

> > For the server / add-on GPU case, we have no known uses for GUI toolkits -
> > only CUDA and GPU-accelerated computation.

> > So from what I know, we should be fine to ship GLES-only Qt on ARM64, and
> > delete any ARM64 binaries from the archive that require GL-enabled Qt.

> so why change something, if we know we won't use it?  If we see the need
> for both stacks, why not keeping the current default, and then go the x86
> way later?  You seem to propose a third way to do it, defaulting to GLES,
> and then adding support for GL if needed.  This looks like extra work, and
> unique to arm64.

I think you're confused here.  We *are* going to be using the Qt GLES stack,
for 64-bit ARM phones / devices.  We have an immediate need for GLES-enabled
Qt because these chips have accelerated GLES drivers, not accelerated GL

And this is exactly the same thing that we already have on armhf, not a
"third way".

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                          
slangasek at                                     vorlon at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the ubuntu-devel mailing list