Upcoming Qt switch to OpenGL ES on arm64

[Andy Simpkins]

On 24/11/2018 02:05, Lisandro Damián Nicanor Pérez Meyer wrote:
> Andy: explicitly CCing you because I think it answers part of a question you
> did but in another part of the thread.
>
> El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
>> On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
> [snip]
>>> Can you build two packages and allow user to select, which one he wants to
>>> install? Or those packages will be binary incompatible?
>> That's a good question, yes. It'w ahst I was wondering too.
> And that's a perfectly valid question, one we did in 2015, Ubuntu tried out
> (as Dmitry pointed out) and did not work.
>
> Why?
>
> Short story: really *too* complicated and error prone.
>
> Long story:
>
> Please first check this image:
>
> <https://qt-kde-team.pages.debian.net/images/qt5_build_deps.png>
>
> That's almost all of Qt for 5.10 (we have now new submodules, so I need to
> update it).
Understood
>
> The Desktop/GLES decision is done at the root of the graph, qtbase. This
> decision changes the API/ABI of libqt5gui5, one of the libraries provided by
> qtbase.
Ack
>
> So, as the API/ABI changes then we would need to (probably) ship two set of
> headers and (for sure) two different libraries, let's say libqt5gui5 for
> Desktop and libqt5gui5gles for GLES.
Yes that sounds right
>
> But it doesn't ends there. The whole graph you saw is actually the *entire*
> Qt. Upstream provides it either as a big fat tarball or as submodules. We took
> the submodules route because building the whole tarball as one would take
> literally days in slow arches.
The time taken for an automated process to run (or fail) should not be a 
justification not to do something.
We need to be able to build the entire archive, not just Qt, and this is 
an automated process.

As an aside: The current arm64 buildd's are plenty fast enough to build 
the entire archive in a few days (IIRC sledge has done this several 
times recently), I also believe that the buildds (and porter boxes?) are 
being (have been?) replaced with newer and faster boxes (also easier for 
DSA to maintain).
I believe that they are also able to build / will build native armhf 
(and armel).  It is my understanding bug reports & fixes are in progress


> And a single mistake could be disastrous.
Not relevant - a single mistake in any package is called a bug. As a 
distribution we have many of these; we strive not to introduce new ones 
and fix those that we can...
> Now whatever switch is applied to qtbase it's "inherited" by the rest of the
> submodules. So if we ship two versions of libqt5gui5 then we would probably
> need to ship two versions of the libs provided by qtdeclarative, which is
> affected by this switch.
Absolutely - everything in the subsystem would need to be duplicated 
up-to the point of common API
> This waterfall schema means *multiple* libraries would have to start doing
> this two-binaries thing, as Ubuntu devs discovered. But remember that Qt is
> really a set of submodules, so in any later version any submodule could start
> using this switch for something. So whatever change could mean yet another set
> of binaries with a transition with multiple rebuilds of the big part of rdeps
> of Qt... no, we don't want to enter that mess.

No. The libraries do not need to have any knowledge about the other 
subsystem / collection of sub modules. i.e. 'desktop' does not need to 
be aware of 'mobile' and vis versa.

>
> So we either keep the status quo of keeping arm64 in Desktop GL or switch to
> GLES. The question is: which use case gives more benefit for our users for the
> next stable release?
>
>>>> So far I personally know 0 people with an arm64 board with PCI slots,
>>>> while I know many with arm64 boards with hardware GLES support.
>>> I'm working with big arm64 iron, so for me a server arm64 board with PCIe
>>> slots (and thus PCIe graphic cards) and on-board Aspeed "VGA card" is more
>>> common compared to GLES-enabled arm64 SoC.
> How many Qt-based applications do you use there? Which ones use OpenGL?
>
>> Yeah - it depends exactly on your background. There's a small (but
>> growing) set of arm64 desktop users, and it would be unfortunate to
>> cut them off.
> Let's be fair: I live almost at the end of the world, probably at very least
> 600 km away from the next DD and in a country in which buying new hardware
> it's not exactly the easiest thing (my current machine, currently the only one
> I have working, is now 10 years old...). So yes, as Steve says, it depends on
> your background.
>
> But even here in this place I have seen *a lot* of "cheap" arm64 boards. Yes,
> the RPI3[+] is ubiquitous. And having to render Open GL stuff by CPU is
> precisely not the fastest thing around.

Right so this is the crux of the matter.

I am putting words in your mouth here - please accept my apologies I am 
trying to describe how I have perceived your comments, this is clearly 
not the words you have used but that is how I am parsing them.  I have 
tried several times to re-word tjis better, it still feels 
confrontational but after several re-writes this is the best 'summery' I 
have been able to generate.

<paraphrase> "I have a Raspberry Pi (or similar mobile class system that 
has migrated / is migrating away from armel to arm64) and this has 
forced a move from 'mobile' OpenGLES to 'Desktop' OpenGL.  The result of 
which is that because that platform (and those like it) do not have 
hardware acceleration for OpenGL but DO for OpenGLES you think we should 
change the whole architecture for your use case." </paraphrase>

My response to that is this:

It is my opinion that having one architecture use OpenGL and another 
OpenGLES was the wrong decision.  Sure for armel (and later armhf) this 
was 'acceptable' - few arm cores before V8 supported PCI / PCIe 
interfaces, so the number of armel boards that were running as a desktop 
environment with 'off the shelf' graphic cards was low (if any).  Those 
arm based boards that did have GPUs on board were (and are) targeted at 
the mobile market where OpenGLES is the preferred route.  Fast forward a 
few years (a decade?) and the world has moved on.  arm V8 (arm84) has 
arrived and the SoCs now shipping are quite capable of desktop through 
to HPC performance levels, as well as the mobile market segment.  The 
decision to just support OpenGLES is perhaps com

Rather than select OpenGL EOR OpenGLES for an architecture we should 
take the time to allow OpenGL EOR OpenGLES per installation.


Sorry I don't buy that as being too complex:

* You already have 'Desktop' OpenGL working on ARM64 (and AMD64 etc 
etc).  You are proposing to drop that and go to 'Mobile' OpenGLES 
(working on armel / armhf).

* I say leave 'Desktop alone'  - it doesn't introduce any new errors.

* I say introduce OpenGLES alongside, this doesn't appear to be the 
imposable task that you are making it out to be:

   * Unpack the tarball from upstream 'Mobile' run a global replace 
against the filenames appending 'gles' - strictly not required but it 
forces a separate name space (avoids potential confusion) <== exact 
mechanism is up for brighter minds than mine to define

   * Build entire 'mobile' subsystem up to and including QT

   * Test

   * For the new 'OpenGLES' package tree make dependencies for 'mobile' 
system require the new '*gles' packages and exclude the existing 
'desktop' packages

   * Change the dependencies for 'desktop' system to add a prohibit of 
the new '*gles' 'mobile'  packages

   * Test

   * Deploy

   * Once done all of the above can then be largely automated making 
tracking upstream of OpenGLES changes fit with whatever mechanism was 
determined above.

   * Test

* Finally we could then add a wrapper package that could 'probe' the 
system to be installed and identify which (if any) OpenGL/OpenGLES is 
accelerated, display the results and ASK THE user which framework they 
want to install.
> But on the other hand most PCI video cards out there can do both GLES and
> Desktop OpenGL. So an arm64-based motherboard which needs nice graphics could
> surely use GLES.
>
> Yes, might not be the best thing out there, but: how many of you are using it
> to render OpenGL stuff with Qt?
>
> And again: you *can* convince me that we better not do the switch, that's
> exactly why we created this thread: we wanted fellow Debian users/developers
> to share their thoughts (and it's working!).

I am not trying to convince you NOT to switch.  I would like to see 
OpenGLES available on arm64.

> So, again: which of the two flavors is the one that benefits more of our user
> base?

BOTH are possible so why dictate only one?

I would like to see OpenGLES available on all architectures

I would like to see OpenGL available on all architectures

I think that there is a relatively painless method to achieve this

I believe this would also meet your needs


Finally - My familiarity with Qt / code skills mean I am unable to do 
the work I am proposing but I can and will spend time testing / building 
automated test suites. This is not something that *you* should do  on 
your own, there are enough people that can help make this happen...

/Andy