Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Rohan Garg]

Hey

On Mon, Nov 26, 2018 at 12:38 PM Raphael Hertzog <hertzog at debian.org> wrote:
>
> Hello Lisandro,
>
> TLDR: thank you for starting this discussion, it was required as it's not
> an easy decision to take as there is no realistic perfect solution, but I
> believe you took the wrong decision. Please consider deferring the
> decision to the technical committe by seeking his advice (point 6.1.3
> of the constitution https://www.debian.org/devel/constitution.en.html#item-6).
>

Having worked on multiple ARM boards over the past 3 years,
I agree very strongly with Raphael.

> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It seems now clear that the general consensus seems to expect:
> > = Qt available for both Desktop and ES OpenGL flavours
> > = If no change is possible, keep arm64 with Desktop OpenGL support
>
> I'm not pleased with how this discussion was handled. First of all,
> you did not leave enough time for all stakeholders to participate in
> the discussion (started on November 22th, closed November 25th, 3 days,
> that's not a reasonable timeframe in particular when 2 of the 3 days
> were in the week-end). I was aware of the discussion but did not
> had the time to chime in, yet I was the person who re-opened the bug
> #881333 in the first place.
>

As the person who opened #881333, I completely agree. I've been on vacation
the past 10 days and haven't had a opportunity to chime in.

> I also invited someone else who is working on a concrete project involving
> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
> now but he also did not have the time to contribute to the discussion.
>

I've had multiple concrete projects involving KDE, Qt and ARM over the past
few years, over multiple ARM platforms such as the ODROID C1, C2 and the
Pinebook. With my KDE hat on, we have a strong stake in having Plasma
perform decently well on these devices.

> Then I have read the whole discussion and I don't have the feeling that
> any consensus has been reached. It was largely driven by Andy Simpkins
> who explained his "gut feeling" as a tinkerer of arm* boards/devices and
> Bret Curtis who contributes to some applications with very specific OpenGL
> needs. While I value their contribution to the discussion, they both
> represent very specific classes of users.
>
> What I remember from this discussion is that the Windows build of Qt
> use GLES 2 by default. It would have been interesting to find out the
> rationale for this... because maybe the right decision for us would be
> to switch to GLES 2 by default as well (on all architectures as jcristau
> suggested). Someone else who likely also tried to ensure Qt for Windows is
> usable on most hardware made that choice.
>
> We got confirmation from many persons that almost all cards benefitting
> from Desktop OpenGL would also work with OpenGL ES. So in terms of
> hardware support, picking OpenGL ES is the right choice. In terms of
> sofware support, it looks like that Desktop OpenGL is better as there
> are a few applications that only work with Desktop OpenGL.
>
> Software can be fixed/improved to also work with OpenGL ES. However
> hardware, once bought, cannot be fixed to support Desktop OpenGL
> when it has been designed for OpenGL ES only.
>

I concur here. It was correctly pointed out in another reply that by using
OpenGL we're specifically catering to software that doesn't support
GLES while making performance worse for mature applications that
do implement both OpenGL and GLES. The reality of the situation is that
the market currently favors GLES over GL on ARM SBC's, delivered with
proprietary blobs. I think a more pragmatic view of this reality would be to
deliver the best FOSS user experience that's possible with the proprietary
drivers while the open source drivers are being improved. To that extent,
by switching to GLES we improve the overall situation since OpenGL
applications can fall back to software rendering via mesa on platforms
where mesa does not support the GPU.

> When taking all this into account, I believe that the right solution is
> to use OpenGL ES on all architectures. This will provide the required
> incentives for application developers who stick only to Desktop OpenGL
> to support OpenGL ES (even it it's at the cost of using some intermediary
> layer like https://github.com/p3/regal) and would maximize hardware
> support on all architectures.
>
> That said, I'm fine with a decision to change only arm64 since that's
> an architecture were devices that support only OpenGL ES are in the
> majority.
>

By choosing to build Qt with GLES on ARM64, we make Debian a more
attractive platform for vendors who'd like to target ARM64 boards.

Cheers
Rohan Garg