On 04.06.2016 00:25, Steve Langasek wrote:
> 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
>>> 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
>> That's fair enough. I guess that's back to the original statement about
>> "Do we really have to cripple an architecture like
>> 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.
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.
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel