Re: Upcoming Qt switch to OpenGL ES on arm64
- Date: Sat, 24 Nov 2018 10:26:34 +0000
- From: Andy Simpkins <rattusrattus@xxxxxxxxxx>
- Subject: Re: Upcoming Qt switch to OpenGL ES on arm64
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:
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.
Short story: really *too* complicated and error prone.
Please first check this image:
That's almost all of Qt for 5.10 (we have now new submodules, so I need to
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
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
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.
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.
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
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...
And a single mistake could be disastrous.
Absolutely - everything in the subsystem would need to be duplicated
up-to the point of common API
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.
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
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
* For the new 'OpenGLES' package tree make dependencies for 'mobile'
system require the new '*gles' packages and exclude the existing
* Change the dependencies for 'desktop' system to add a prohibit of
the new '*gles' 'mobile' packages
* Once done all of the above can then be largely automated making
tracking upstream of OpenGLES changes fit with whatever mechanism was
* 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
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...