<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial">Hi All£¬<br>We have ARM64 devices used AMD Radeon Series graphics cards¡£So£¬same as x86 we really need a full OpenGL <span id="result_box" class="short_text" lang="en"><span class="">Qt support </span></span>With ARM64 ¡£<br><br><pre><br>At 2016-06-04 08:48:17, "Steve Langasek" <steve.langasek@ubuntu.com> wrote:
>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
</pre></div>