Web lists-archives.com

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:
[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