Upcoming Qt switch to OpenGL ES on arm64

Sat Nov 24 14:41:09 GMT 2018

Hi Andy!

El sábado, 24 de noviembre de 2018 07:26:34 -03 Andy Simpkins escribió:
> 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.

Except for the *manpower* needed behind it. We are currently 2 to 3 active 
developers for the whole Qt stack and we can't certainly add more work to our 
stack. We are really behind what we would really like to be doing, like 
enabling all the source's tests.

> 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.

Except a whole lot of libraries would need double build. Ideallistically 
doable, but not with the current manpower behind it.

> > 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.

Please, be my guest. So far I have found a nicely worded mail with differents 
points of view, nothing more.

> <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.

Ideally: yes, I would certainly agree. But with current Qt's code that's just 
almost impssible except you have a team of dedicated people to it. Ubuntu kind 
of had, they could not. We don't have, we are just contributors of our free 
time.

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

Well, I could invite you to join us maintaining Qt and it's ecosystem ;-)

> * 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.

Again, tried by people with more resources that us, discarded.

> > 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 hope to have maked my point before :-)

> I would like to see OpenGLES available on all architectures

Me too.

> I would like to see OpenGL available on all architectures

Me too.

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

That's *exactly* where we disagree.

> 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...

Whoever needs to set up this needs to have firm knowledge of packaging C+ 
libraries and Qt.

-- 
mathematician, n.:
        Some one who believes imaginary things appear right before your i's.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-kde-talk/attachments/20181124/365dd95e/attachment-0001.sig>