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
drivers.
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 http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
