On Fri, Jun 03, 2016 at 03:56:14PM -0500, Kevin Gunn wrote:
> > Ubuntu supports a growing number of ARM servers that have PCIe slots,
> > so external GPUs can be added. CUDA is supported on those platforms
> > upstream:
> > https://developer.nvidia.com/cuda-toolkit-65
> > And I do know there are users interested in CUDA on Ubuntu/arm64.
> > I'm not experienced with CUDA myself - and don't have a card to test it
> > - but it would be good to know if we're breaking that use case ahead of
> > time.
> That's fair enough. I guess that's back to the original statement about
> "Do we really have to cripple an architecture like
> >> this?"
> It's not about the arch per se it's more about having offerings that match
> Gpus attached to that arch. So does it make sense to leave them in place
> and just know you'll have build failures in some cases?
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.
Either way, we're not going to leave unbuildable binaries hanging around in
the archive.
--
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
