Re: Upcoming Qt switch to OpenGL ES on arm64

[Gene Heskett]

On Saturday 24 November 2018 14:36:11 bret curtis wrote:

> > > There are more than 5 million Raspberry Pis were sold as of
> > > February 2015. All of them with a VC4 GPU, Raspbian ships with the
> > > VC4 mesa driver enabled!
> > >
> > > I'm of the opinion that the switch away from Desktop OpenGL to
> > > GLES was a huge mistake and should be reversed as soon as possible
> > > unless there is a way to provide for both on all archtictures.
> >
> > Well, f you can prove this for armhf and/or armel, we can certainly
> > do it.
>
> The Raspberry Pi is armhf. What would you like me to prove? Sadly I
> can't help you with armel, but with armhf, according to some sources
> the number of RPi's sold in the last 5 years is 12 million [1].
> Admidetly, not all of them will be used as a desktop, but it is still
> nothing to sneeze at and it is shame that we've had to prevent
> compiling OpenMW on armhf and armel just because Qt was compiled
> against GLES. We've had to introduce "libqt5opengl5-dev,
> libqt5opengl5-desktop-dev [armel armhf]" in the debian/control file as
> a result. [2] This makes sure that OpenMW can't ever be built on on
> armel and armhf with "BD-Uninstallable". [3]
>
> openmw build-depends on missing:
> - libqt5opengl5-desktop-dev:armhf
> ^-- sad state of affairs that this even exists!
>
> [1]
> https://www.theverge.com/circuitbreaker/2017/3/17/14962170/raspberry-p
>i-sales-12-5-million-five-years-beats-commodore-64 [2]
> https://salsa.debian.org/games-team/openmw/blob/master/debian/control#
>L12 [3] https://buildd.debian.org/status/package.php?p=openmw

I think you just helped me make a point, and that point is that 
debian-arm, with this decision, is throwing the pi users under the bus 
and gunning it while leaving,

I'm on SS for income, nominally $1600 a month. I am also a great believer 
in TANSTAAFL. Take up a collection from tsome of the 12 million armhf/64 
users to hire another armhf/arm64 coder or 2, I'm in for a $50 
donation/year until I fall over or we have an os the equal of the 
desktops in everything but speed, and kernels suitable for realtime 
control apps.

How about it arm users, deal? Somebody has to pay the bills, and if it 
gets us the stuff we need, why not. Think TANSTAAFL.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Upcoming Qt switch to OpenGL ES on arm64

[bret curtis]

Hey Scott,


On Sat, Nov 24, 2018 at 9:01 PM Scott Kitterman  wrote:
>
> On Saturday, November 24, 2018 08:36:11 PM bret curtis wrote:
>
> We have a Rasberry Pi working as a desktop here at my house.  It's quite
> usable as long as you only try to do a few things at a time, but it's not by
> any means zippy.  I strongly suspect that moving back from GLES would move it
> from "reasonable for limited use" to "pointless".  Please don't do anything to
> make things even slower.
>
> Scott K
>

It's because of the VC4 mesa driver that the RPi is usable for you,
reasonable for limited use. Not using VC4, but the CPU based llvmpipe,
is what makes it pointless and almost too slow to use as a desktop. If
you don't have VC4 enabled, I suggest you give it a try, it's a world
of difference.

Moving Qt back to using Desktop GL from GLES is going to have zero
impact performance on the RPi since the VC4 supports up to OpenGL 2.1
and and GLES 2.0 [1]

The problem is that there are applications that make use of Qt that do
not support GLES while Qt can support both. So these things can't be
shipped on armel and armhf and now possibly arm64.

What applications does Debian have in its repo that only support GLES?

Cheers,
Bret

[1] https://github.com/anholt/mesa/wiki/VC4-OpenGL-support

Re: Upcoming Qt switch to OpenGL ES on arm64

[Scott Kitterman]

On Saturday, November 24, 2018 08:36:11 PM bret curtis wrote:
> > > There are more than 5 million Raspberry Pis were sold as of February
> > > 2015.
> > > All of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver
> > > enabled!
> > > 
> > > I'm of the opinion that the switch away from Desktop OpenGL to GLES was
> > > a
> > > huge mistake and should be reversed as soon as possible unless there is
> > > a
> > > way to provide for both on all archtictures.
> > 
> > Well, f you can prove this for armhf and/or armel, we can certainly do it.
> 
> The Raspberry Pi is armhf. What would you like me to prove? Sadly I
> can't help you with armel, but with armhf, according to some sources
> the number of RPi's sold in the last 5 years is 12 million [1].
> Admidetly, not all of them will be used as a desktop, but it is still
> nothing to sneeze at and it is shame that we've had to prevent
> compiling OpenMW on armhf and armel just because Qt was compiled
> against GLES. We've had to introduce "libqt5opengl5-dev,
> libqt5opengl5-desktop-dev [armel armhf]" in the debian/control file as
> a result. [2] This makes sure that OpenMW can't ever be built on on
> armel and armhf with "BD-Uninstallable". [3]
> 
> openmw build-depends on missing:
> - libqt5opengl5-desktop-dev:armhf
> ^-- sad state of affairs that this even exists!

We have a Rasberry Pi working as a desktop here at my house.  It's quite 
usable as long as you only try to do a few things at a time, but it's not by 
any means zippy.  I strongly suspect that moving back from GLES would move it 
from "reasonable for limited use" to "pointless".  Please don't do anything to 
make things even slower.

Scott K

Re: Upcoming Qt switch to OpenGL ES on arm64

[bret curtis]

> >
> > There are more than 5 million Raspberry Pis were sold as of February 2015.
> > All of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver
> > enabled!
> >
> > I'm of the opinion that the switch away from Desktop OpenGL to GLES was a
> > huge mistake and should be reversed as soon as possible unless there is a
> > way to provide for both on all archtictures.
>
> Well, f you can prove this for armhf and/or armel, we can certainly do it.
>

The Raspberry Pi is armhf. What would you like me to prove? Sadly I
can't help you with armel, but with armhf, according to some sources
the number of RPi's sold in the last 5 years is 12 million [1].
Admidetly, not all of them will be used as a desktop, but it is still
nothing to sneeze at and it is shame that we've had to prevent
compiling OpenMW on armhf and armel just because Qt was compiled
against GLES. We've had to introduce "libqt5opengl5-dev,
libqt5opengl5-desktop-dev [armel armhf]" in the debian/control file as
a result. [2] This makes sure that OpenMW can't ever be built on on
armel and armhf with "BD-Uninstallable". [3]

openmw build-depends on missing:
- libqt5opengl5-desktop-dev:armhf
^-- sad state of affairs that this even exists!

[1] 
https://www.theverge.com/circuitbreaker/2017/3/17/14962170/raspberry-pi-sales-12-5-million-five-years-beats-commodore-64
[2] https://salsa.debian.org/games-team/openmw/blob/master/debian/control#L12
[3] https://buildd.debian.org/status/package.php?p=openmw

Re: Upcoming Qt switch to OpenGL ES on arm64

[Gene Heskett]

On Saturday 24 November 2018 10:29:08 Steve McIntyre wrote:

> On Sat, Nov 24, 2018 at 10:10:04AM -0500, Gene Heskett wrote:
> >And the OpenGL driver is of zero use to me until a preemp-rt, or full
> >RTAI kernel accompanies it. Once that becomes available, and more
> > pi's are in the supply line, you will see an explosion of pi's
> > running cnc machinery. Why? Because we also have an SPI driver as
> > part of LinuxCNC that actually works, at mind boggling data rates.
>
> Sorry Gene, but that's utterly irrelevant to this discussion. We know
> you're interested in LinuxCNC, but not everybody is...

Is there src for this magic that might build against that kernel I'm 
using? git url?

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Upcoming Qt switch to OpenGL ES on arm64

[Steve McIntyre]

On Sat, Nov 24, 2018 at 10:10:04AM -0500, Gene Heskett wrote:
>
>And the OpenGL driver is of zero use to me until a preemp-rt, or full 
>RTAI kernel accompanies it. Once that becomes available, and more pi's 
>are in the supply line, you will see an explosion of pi's running cnc 
>machinery. Why? Because we also have an SPI driver as part of LinuxCNC 
>that actually works, at mind boggling data rates.

Sorry Gene, but that's utterly irrelevant to this discussion. We know
you're interested in LinuxCNC, but not everybody is...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back

Re: Upcoming Qt switch to OpenGL ES on arm64

[Gene Heskett]

On Saturday 24 November 2018 09:14:48 bret curtis wrote:

> > > 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.
> >
> >  "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."
> > 
>
> This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> if you plan on having hardware accelerated X11 or Wayland, you need
> the VC4 driver. You'll need "Desktop" OpenGL otherwise nothing will
> work on a RPi system, which as of 2015 has over 5 million units
> shipped. This is not an insignificant user base.
>
That was 2015? I would at least triple that figure now. I bought 3, 2 
years ago, blew one, and still have 2. I went to buy two more a few 
months back, sold out. More on order.  So that project got put on hold.

> IMHO, the decision to switch away from 'Desktop' OpenGL to GLES was
> the wrong decision and should be reversed until a solution is found to
> support both.

+1

And the OpenGL driver is of zero use to me until a preemp-rt, or full 
RTAI kernel accompanies it. Once that becomes available, and more pi's 
are in the supply line, you will see an explosion of pi's running cnc 
machinery. Why? Because we also have an SPI driver as part of LinuxCNC 
that actually works, at mind boggling data rates.

> Cheers,
> Bret



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

El sábado, 24 de noviembre de 2018 11:23:51 -03 bret curtis escribió:
> Hello Lisandro!
> 
> > Yes, that's a drawback we are not hiding. Applications needing Desktop
> > OpenGL would be left out. But...
> 
> Sorry, but this is just not acceptable. There has to be another way.
> 
> > > If you say that arm64 has to be GLESv2 as well, then that is yet another
> > > arch that OpenMW can't be built for.  Before the GLESv2 switch, OpenMW
> > > worked just fine on arm* hardware, including the Raspberry Pi/Raspbian
> > > with
> > > the VC4 mesa driver that has OpenGL 2.0 support.
> > 
> > ...one thing is running and quite another is: how well does it performs
> > when doing 100% CPU-based OpenGL? Are your users *really* interested to
> > use your application when all drawing must be CPU-based?
> 
> There is a misunderstanding here and also in this thread. The Raspberry Pi
> has the VC4 GPU which is hardware accelerated Desktop OpenGL 2.1 via the
> VC4 Mesa driver.[1] This driver is fully open-source unlike the binary blob
> it comes with that only supports GLESv2, but not via X11 nor Wayland.

Ok, that's totally new for me. And indeed it changes the way (at least I) see 
things.

> So the only way to support Qt with hardware (not software) accelerated GL on
> the RPi is with the VC4 mesa driver and Desktop GL.

Point taken.

> As for OpenMW running on a RPi, it is fully hardware (GPU) accelerated via
> the VC4 driver. It runs pretty darn well. You can walk around Morrowind
> (with mods) right now at 25fps @ 1080p using a GPU-based VC4[1] OpenGL 2.0
> renderer. 60fps in interiors. This is on a Raspberry Pi 2, likely better
> with the RPi3 with VC4 being EoL, the next iteration of the RPi will likely
> be VC5/6 that is arm64.
> 
> > > I beg you, please either reverse the GLES decision in Qt or provide two
> > > separate packages for GL or GLES support.
> > 
> > I'm afraid providing two set ups is a non-go (alas, we would be doing that
> > already and avoiding all this). And I don't there are many armel/armhf
> > users with hardware Desktop OpenGL in their boards.
> 
> There are more than 5 million Raspberry Pis were sold as of February 2015.
> All of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver
> enabled!
> 
> I'm of the opinion that the switch away from Desktop OpenGL to GLES was a
> huge mistake and should be reversed as soon as possible unless there is a
> way to provide for both on all archtictures.

Well, f you can prove this for armhf and/or armel, we can certainly do it.

-- 
7: Hay diferencia entre "cortar" un archivo y "borrarlo" o "eliminarlo"
* Depende cuando se "cuelgue" Windows
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Andy Simpkins]

On 24/11/18 14:14, bret curtis wrote:
>>> 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.
>>
>>  "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." 
>>
> 
> This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> if you plan on having hardware accelerated X11 or Wayland, you need
> the VC4 driver. You'll need "Desktop" OpenGL otherwise nothing will
> work on a RPi system, which as of 2015 has over 5 million units
> shipped. This is not an insignificant user base.
> 
> IMHO, the decision to switch away from 'Desktop' OpenGL to GLES was
> the wrong decision and should be reversed until a solution is found to
> support both.
> 
> Cheers,
> Bret
> 

Apologies for using the RaspberryPi as my example of a 'mobile' class SoC.

IIRC the Pi was being used as the primary argument for switching away
from OpenGL to OpenGLES as this is selling in large volumes.  If the Pi
already supports OpenGL then the argument to move solely to OpenGLES is
reduced somewhat.

I will try OpenGL on a RPi this week (I normally run RPi headless so no
desktop installed).

/Andy

Re: Upcoming Qt switch to OpenGL ES on arm64

[bret curtis]

Hello Lisandro!

> Yes, that's a drawback we are not hiding. Applications needing Desktop OpenGL
> would be left out. But...
>

Sorry, but this is just not acceptable. There has to be another way.

>
> > If you say that arm64 has to be GLESv2 as well, then that is yet another
> > arch that OpenMW can't be built for.  Before the GLESv2 switch, OpenMW
> > worked just fine on arm* hardware, including the Raspberry Pi/Raspbian with
> > the VC4 mesa driver that has OpenGL 2.0 support.
>
> ...one thing is running and quite another is: how well does it performs when
> doing 100% CPU-based OpenGL? Are your users *really* interested to use your
> application when all drawing must be CPU-based?

There is a misunderstanding here and also in this thread. The Raspberry Pi has
the VC4 GPU which is hardware accelerated Desktop OpenGL 2.1 via the VC4 Mesa
driver.[1] This driver is fully open-source unlike the binary blob it comes with
that only supports GLESv2, but not via X11 nor Wayland.

So the only way to support Qt with hardware (not software) accelerated GL on
the RPi is with the VC4 mesa driver and Desktop GL.

As for OpenMW running on a RPi, it is fully hardware (GPU) accelerated via the
VC4 driver. It runs pretty darn well. You can walk around Morrowind (with mods)
right now at 25fps @ 1080p using a GPU-based VC4[1] OpenGL 2.0 renderer.
60fps in interiors. This is on a Raspberry Pi 2, likely better with the
RPi3 with VC4 being EoL, the next iteration of the RPi will likely be VC5/6
that is arm64.

> > I beg you, please either reverse the GLES decision in Qt or provide two
> > separate packages for GL or GLES support.
>
> I'm afraid providing two set ups is a non-go (alas, we would be doing that
> already and avoiding all this). And I don't there are many armel/armhf users
> with hardware Desktop OpenGL in their boards.
>

There are more than 5 million Raspberry Pis were sold as of February 2015. All
of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver enabled!

I'm of the opinion that the switch away from Desktop OpenGL to GLES was a huge
mistake and should be reversed as soon as possible unless there is a way to
provide for both on all archtictures.

Cheers,
Bret

[1] https://github.com/anholt/mesa/wiki/VC4

Re: Upcoming Qt switch to OpenGL ES on arm64

[Lisandro Damián Nicanor Pérez Meyer]

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

Re: Upcoming Qt switch to OpenGL ES on arm64

[bret curtis]

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

This is a very wrong assumption, the OpenGL on a RPi (all of them) is
hardware accelerated via the VC4 mesa driver by Eric Anholt which is
shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
if you plan on having hardware accelerated X11 or Wayland, you need
the VC4 driver. You'll need "Desktop" OpenGL otherwise nothing will
work on a RPi system, which as of 2015 has over 5 million units
shipped. This is not an insignificant user base.

IMHO, the decision to switch away from 'Desktop' OpenGL to GLES was
the wrong decision and should be reversed until a solution is found to
support both.

Cheers,
Bret

Re: Upcoming Qt switch to OpenGL ES on arm64

[Sune Vuorela]

On 2018-11-24, Andy Simpkins  wrote:
> BOTH are possible so why dictate only one?

Because it would require two flavours of all users.

/Sune

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



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