Upcoming Qt switch to OpenGL ES on arm64

[Dmitry Shachnev]

Hi all!

The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
support. At the moment we are building it with OpenGL ES on armel and armhf,
and with desktop OpenGL on all other architectures.

However we have received a request [1] from two different persons to add arm64
to the list of architectures where OpenGL ES is used.

We want your feedback! If you are using an arm64 device or board with Qt,
please let us know your opinion about this change, by replying to this mail
or to [1], and describe your use case.

So far we are going to make this change starting with the Qt 5.11.3 packages.
In case you already want to test it, the updated qtbase package is available
in experimental [2]. However the reverse dependencies are not yet rebuilt.

This change will affect packages using Qt Gui [3], Qt Widgets [4], Qt Quick
and some other modules. It will not affect packages using the deprecated Qt
OpenGL module because it loads the OpenGL library at runtime.

The best way to check whether some package needs changes is checking Ubuntu
[5], which has been building Qt with OpenGL ES on arm64 since version 16.10
(yakkety) [6].

We will send a new mail with DD-list of packages that we detect to be affected
a bit later.

There are some packages that are not compatible with OpenGL ES. For example,
packages using libglu and Qt simultaneously will most likely have to drop
their arm64 binaries (like they already have no armel or arm64 binaries).
An example of such package is qwtplot3d.

Also note that as this change breaks ABI on arm64, we are renaming libqt5gui5
to libqt5gui5a, which will need binNMUs of all reverse dependencies. The list
of all such dependencies is available here [7]. This will happen together with
the Qt 5.11.3 transition.

Please Cc me or pkg-kde-talk on reply.

[1]: https://bugs.debian.org/881333
[2]: https://tracker.debian.org/news/1004843/
[3]: https://doc.qt.io/qt-5/qtgui-index.html#opengl-and-opengl-es-integration
[4]: https://doc.qt.io/qt-5/qopenglwidget.html
[5]: https://launchpad.net/ubuntu/+source/${SOURCE_PACKAGE_NAME},
or the “ubuntu patches” link in the right panel of tracker.debian.org
[6]: https://salsa.debian.org/qt-kde-team/qt/qtbase/commit/197063f08928ac9c
[7]: https://perezmeyer.com.ar/ben/qtbase.html

--
Dmitry Shachnev

[Marcin Juszkiewicz]

The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
support. At the moment we are building it with OpenGL ES on armel and armhf,
and with desktop OpenGL on all other architectures.
However we have received a request [1] from two different persons to add arm64
to the list of architectures where OpenGL ES is used.
We want your feedback! If you are using an arm64 device or board with Qt,
please let us know your opinion about this change, by replying to this mail
or to [1], and describe your use case.

Does it mean that arm64 box with PCI Express graphics card will be not
able to use Qt based software? I can put Radeon or NVidia card into my
box and use it as a normal OpenGL accelerated desktop (did that already
few years ago).

From what I see the problem is with Qt not being able to be built with

support for both OpenGL and OpenGLES ;(

[John Paul Adrian Glaubitz]

Post by Marcin Juszkiewicz

The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
support. At the moment we are building it with OpenGL ES on armel and armhf,
and with desktop OpenGL on all other architectures.
However we have received a request [1] from two different persons to add arm64
to the list of architectures where OpenGL ES is used.
We want your feedback! If you are using an arm64 device or board with Qt,
please let us know your opinion about this change, by replying to this mail
or to [1], and describe your use case.

Does it mean that arm64 box with PCI Express graphics card will be not
able to use Qt based software? I can put Radeon or NVidia card into my
box and use it as a normal OpenGL accelerated desktop (did that already
few years ago).

Correct. After this switch, Qt on arm64 will be forced into embedded mode when it comes to graphics.

Not sure whether it’s the right decision to be made. Might be an idea to ask more users on their opinions on this issue.

Granted, I don’t really know what the real world distribution of embedded and desktop/server/laptop devices of arm64 is. But I could imagine that there will be more arm64 devices in the future which are desktops, servers or laptops.

Adrian

[W. Martin Borgert]

Post by John Paul Adrian Glaubitz
Granted, I don’t really know what the real world distribution of
embedded and desktop/server/laptop devices of arm64 is. But I could
imagine that there will be more arm64 devices in the future which
are desktops, servers or laptops.

There is e.g. this project from Berlin:

https://mntmn.com/reform/

It says:

* Vivante GC3000 GPU
Fully open source drivers in the Linux kernel (etnaviv)
and OpenGL (mesa)

I will buy one as soon as available.

There is also Novena:

https://www.crowdsupply.com/sutajio-kosagi/novena

No idea what they use for graphics.

Cheers

[Julien Cristau]

Post by Marcin Juszkiewicz

The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
support. At the moment we are building it with OpenGL ES on armel and armhf,
and with desktop OpenGL on all other architectures.
However we have received a request [1] from two different persons to add arm64
to the list of architectures where OpenGL ES is used.
We want your feedback! If you are using an arm64 device or board with Qt,
please let us know your opinion about this change, by replying to this mail
or to [1], and describe your use case.

Does it mean that arm64 box with PCI Express graphics card will be not
able to use Qt based software? I can put Radeon or NVidia card into my
box and use it as a normal OpenGL accelerated desktop (did that already
few years ago).

At least mesa drivers can be used for desktop GL or GLESv2 just fine,
AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
architectures, to stop the special-casing madness, instead of making it
spread? :)

Cheers,
Julien

[Lisandro Damián Nicanor Pérez Meyer]

Post by Julien Cristau

Post by Marcin Juszkiewicz

Post by Dmitry Shachnev
The Qt framework can be built either with “desktop” OpenGL, or with
OpenGL ES support. At the moment we are building it with OpenGL ES on
armel and armhf, and with desktop OpenGL on all other architectures.
However we have received a request [1] from two different persons to add
arm64 to the list of architectures where OpenGL ES is used.
We want your feedback! If you are using an arm64 device or board with Qt,
please let us know your opinion about this change, by replying to this mail
or to [1], and describe your use case.

Does it mean that arm64 box with PCI Express graphics card will be not
able to use Qt based software? I can put Radeon or NVidia card into my
box and use it as a normal OpenGL accelerated desktop (did that already
few years ago).

At least mesa drivers can be used for desktop GL or GLESv2 just fine,
AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
architectures, to stop the special-casing madness, instead of making it
spread? :)

That would mean that anything using Qt + [GLU[T] glew] will have to get
removed from the archive.

Now let's suppose for a minute that the above could be solvable: it would be
good to know whether this is in fact a possible solution.

In this case the question would be: do the major part of the video cards out
there support GLES?

[Gene Heskett]

On Thursday 22 November 2018 17:27:35 Lisandro Damián Nicanor Pérez Meyer

El jueves, 22 de noviembre de 2018 19:05:27 -03 Julien Cristau

Post by Julien Cristau

Post by Marcin Juszkiewicz

The Qt framework can be built either with “desktop” OpenGL, or
with OpenGL ES support. At the moment we are building it with
OpenGL ES on armel and armhf, and with desktop OpenGL on all
other architectures.
However we have received a request [1] from two different persons
to add arm64 to the list of architectures where OpenGL ES is
used.
We want your feedback! If you are using an arm64 device or board
with Qt, please let us know your opinion about this change, by
replying to this mail
or to [1], and describe your use case.

Does it mean that arm64 box with PCI Express graphics card will be
not able to use Qt based software? I can put Radeon or NVidia card
into my box and use it as a normal OpenGL accelerated desktop (did
that already few years ago).

At least mesa drivers can be used for desktop GL or GLESv2 just
fine, AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
architectures, to stop the special-casing madness, instead of making
it spread? :)

That would mean that anything using Qt + [GLU[T] glew] will have to
get removed from the archive.
Now let's suppose for a minute that the above could be solvable: it
would be good to know whether this is in fact a possible solution.
In this case the question would be: do the major part of the video
cards out there support GLES?

This reply is going to indict far more than just the video you are
referring to although it is included.

I think a better question would be: Does it improve, or disable, decent
video support for the dozens of arm64 cards in the r-pi format, such as
the arm64 based $44 rock64? It has great hardware specs, 4 gigs of
system ram, a 4 core arm64 cpu running faster than most of the sbc's,
but no support for installing either a realtime kernel so it can run
machine controller apps, which use the spi to talk to controller cards
with 3x the pcb real estate than the rock64 itself. Its spi is glacial
compared to what can be done on a far less well endowed r-pi-3b, which
can write to the controller card at 42 megabaud, and read its response
at 25 megabaud, and so far it seems that broadcom patents (from what
I've read) are preventing any linux use of the mali video chips it has,
leaving it with framebuffer only video if the install is linux. You
don't run real world app's with a 6 frames a second video.

All but one of the jessie/stretch system's available for the arm**'s
today, have the first user=1000 hard coded, only the armbian stretch
allows the first user to be created on first boot.

You would be doing the developer world for such sbc's a lot more good,
making it run well on a $44 sbc. What I'm reading here seems only to
apply to systems in the thousand dollar and up category.

My $0.02.

[Dmitry Shachnev]

Post by Gene Heskett
I think a better question would be: Does it improve, or disable, decent
video support for the dozens of arm64 cards in the r-pi format, such as
the arm64 based $44 rock64? [...]

As far as I know Raspberry Pi 3 and similar devices work fine with OpenGL ES.

E.g. Raspbian does not override our choice to build qtbase with OpenGL ES
on armhf.

--
Dmitry Shachnev

[Gene Heskett]

Post by Dmitry Shachnev

Post by Gene Heskett
I think a better question would be: Does it improve, or disable,
decent video support for the dozens of arm64 cards in the r-pi
format, such as the arm64 based $44 rock64? [...]

As far as I know Raspberry Pi 3 and similar devices work fine with OpenGL ES.
E.g. Raspbian does not override our choice to build qtbase with OpenGL
ES on armhf.
--
Dmitry Shachnev

Not on my machine, which because its running real machinery, has
something like a realtime kernel substituted into a jessie lite install
so the kernel and matching lib are pinned to keep apt from installing
non-realtime stuff. And recovering from a kernel update that apt wants
to install involves building a whole new sd card since its impossible to
make an image with dd that fits on the next sd card, no 2 are the exact
same size but doesn't because of the pinning, so your OpenGL ES update
is not done.

So first I need a new realtime kernel and library that will live with
your OpenGL ES. I have downloaded and built several linux-rt kernels on
this pi as I've attached a 60 GB SSD, but there is no installer I have
been able to find, and no one wants to tell me where to find one that
works with the weird partitioning scheme the pi's boot loader uses.

These so-called realtime kernels I've tried all suffer from an un-init'd
var someplace that causes keyboard and mouse events to be thrown away
until its been rebooted several times and finally hits a sweet spot and
works until the next power bump.

The kernel it runs best is a bit old, uname reports:
Linux picnc 4.4.4-rt9-v7+ #7 SMP PREEMPT RT Mon Mar 7 14:53:11 UTC 2016
armv7l GNU/Linux

But newer ones I've tried, do the throwaway events thing much worse, the
keyup event being lost the machine continues its jog until you hit the
power switch or pound on the keyboard until a keyup event gets thru.
On the SSD, I have linux-rpi-4.14.y-rt, and linux-rt-devel-4.16.18-rt9
ready for a test install, but nothing to do the actual install to the sd
card. The makefile doesn't know how to do it on the pi-3b. Since Stephan
R's mandate about file locks being done wrong there has been quite a
flurry of patches but no on is claiming a stable build yet. But I am
marking the msgs with git links anyway.

I see the rt folks have been releasing new stuff (I'm lurking on their
list) at a high rate recently, so I should pull and build one again.
And I've quite a pile of 32GB sd cards just waiting for a good rt kernel
for the pi's. But it seems u-boot demands stuff at fixed addresses in
the boot media. Meaning the install is usually by writing a new sd card.

Not Funny thing is, I have seen apt install a new kernel on the rock64
running armbian stretch, since its also a u-boot booter, proof that it
can actually be done on a live system, arm64 in that case.

[Dmitry Shachnev]

Post by Julien Cristau
At least mesa drivers can be used for desktop GL or GLESv2 just fine,
AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
architectures, to stop the special-casing madness, instead of making it
spread? :)

According to config_help.txt [1], Qt uses ES2 by default on Windows.
It probably means that it will work fine with most desktop video cards.

But as Lisandro says, such a change in Debian will break many packages
(which are currently broken on ARM only), so we are definitely not
considering it at this point.

[1]: https://code.qt.io/cgit/qt/qtbase.git/tree/config_help.txt#n271

--
Dmitry Shachnev

[Julien Cristau]

Post by Dmitry Shachnev

Post by Julien Cristau
At least mesa drivers can be used for desktop GL or GLESv2 just fine,
AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
architectures, to stop the special-casing madness, instead of making it
spread? :)

According to config_help.txt [1], Qt uses ES2 by default on Windows.
It probably means that it will work fine with most desktop video cards.
But as Lisandro says, such a change in Debian will break many packages
(which are currently broken on ARM only), so we are definitely not
considering it at this point.

Why is it OK to break them on arm64 if it's not OK to break them on
amd64? Do you have a list of those packages?

Cheers,
Julien

[Dmitry Shachnev]

Post by Julien Cristau

Post by Dmitry Shachnev
According to config_help.txt [1], Qt uses ES2 by default on Windows.
It probably means that it will work fine with most desktop video cards.
But as Lisandro says, such a change in Debian will break many packages
(which are currently broken on ARM only), so we are definitely not
considering it at this point.

Why is it OK to break them on arm64 if it's not OK to break them on
amd64? Do you have a list of those packages?

The majority of arm64 devices are mobile/embedded, which cannot be said
about amd64.

Of course it is bad to break packages, but leaving arm64 users with
non-working Qt graphics is also not ideal. So we are trying to find a
compromise solution here.

We do not have a final list yet, but packages that may get broken will
likely belong to one of these two groups:

- Packages that build-depend on both qtbase5-dev and libglu1-mesa-dev:

cgal, flightgear, fraqtive, kalgebra, kstars, ksudoku, kubrick, paraview,
simplescreenrecorder, starpu, starpu-contrib, structure-synth, vtk6, vtk7

- Packages that build-depend on libqt5opengl5-desktop-dev:

bino, deepin-movie-reborn, enki-aseba, fracplanet, fraqtive, freecad,
krita, libconfig-model-dpkg-perl, mldemos, mm3d, openms, qwtplot3d,
shelxle, soundscaperenderer, tetzle, virtualjaguar, vite, vtk7

This is not a final list yet, but should be enough to get an estimate.

--
Dmitry Shachnev

[Sune Vuorela]

Post by Julien Cristau
Why is it OK to break them on arm64 if it's not OK to break them on
amd64? Do you have a list of those packages?

Because most people on arm64 don't have the hardware.

Rather give them fewer packages that works great rather than many
packages that doesn't really work.

For each arch the Qt maintainers have the choice

1) gles
2) desktop gl

if 1) is chosen, then that exposes one set of api (&abi). If 2) is
chosen it is a different one.

In debian, currently desktop gl is chosen on purpose on typical desktop
architectures (e.g. amd64 and i386), and gles is chosen on purpose on
armel and armhf.

On other archs, desktopgl has just been what has been defaulted to.

Not specifically putting arm64 in the bucket with armel and armhf is a
bug, and one that we should fix.

Yes. Some packages will need to be removed. And a few users will get
burned by that. But hopefully even more users will be happier.

/Sune

[Raphael Hertzog]

Hi,

Post by Dmitry Shachnev
According to config_help.txt [1], Qt uses ES2 by default on Windows.

Interesting.

Post by Dmitry Shachnev
But as Lisandro says, such a change in Debian will break many packages
(which are currently broken on ARM only), so we are definitely not
considering it at this point.

If those packages were broken on all architectures, I expect more people
will start to care about the problem and it might end up fixed. Right now
if affects almost nobody and the problem languishes...

Cheers,

[Riku Voipio]

Post by Marcin Juszkiewicz
Does it mean that arm64 box with PCI Express graphics card will be not
able to use Qt based software? I can put Radeon or NVidia card into my
box and use it as a normal OpenGL accelerated desktop (did that already
few years ago).

"Depends". The change is only for software using some specific classes inside
libqt5gui5. If your video card supports GLES (aka OpenGL ES) then you should
be fine.

Mesa based nouveau, radeon and freedreno should support both - so the
deskop env itself should work I think.

The real issue here is that *many* arm64 boards currently do not support
Desktop OpenGL, but do support GLES.

The boards may or may not support Desktop GL. As far as debian is
concerned, they remain headless devices until they have free drivers.

See, most of the propiertary GLES drivers are craptastic and don't work
with Debians kernel. Even ff you manage to dance the right kernel, device
tree and userspace combo, you may still not get the desktop enviroment
up. And nobody is going to fix the bugs you encounter.

Debian does support Qualcomm based boards with freedreno driver, and
work is progressing with etnaviv for Vivante. Both based on Mesa and
support both OpenGL and GLES. With the MALI reverse engineering active
again, it would seem rather short-sighted and counterproductive to
put lots of energy in supporting the propiertary drivers.

Also applications using GLU[T] or glew will not be able to compile anymore on
arm64. GLU[T] has not been ported to GLES, glew somehow differs in a type
definition.

I have an Synquacer box with nvidia card running Lxqt desktop, running
fine most tasks. While none of the apps I run on it seem to be of the
Qt + GLU/glew combo, it would be unfortunate if I ever need to use them.

Riku

[Lisandro Damián Nicanor Pérez Meyer]

Post by Dmitry Shachnev
Hi all!
The Qt framework can be built either with “desktop” OpenGL, or with OpenGL
ES support. At the moment we are building it with OpenGL ES on armel and
armhf, and with desktop OpenGL on all other architectures.

Maybe we missed to properly explain the main point of this change: currently
most arm64 boards are using software rasterization because their video cards
do not support Desktop OpenGL. If we switch to GLES then most amr64 boards
will be able to render using their video hardware, thus greatly improving
speed to the point of being actually usable for some stuff.

I imagine (but would *love* hard data) that any PCI video card added to an
arm64 machine will probably also support GLES, so they will still have use.

But one thing is for sure: it's not a decision in which everyone wins, so we
are trying to make a decision on which *most* of our users wins.

[Gene Heskett]

On Thursday 22 November 2018 17:33:50 Lisandro Damián Nicanor Pérez Meyer

El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev

Post by Dmitry Shachnev
Hi all!
The Qt framework can be built either with “desktop” OpenGL, or with
OpenGL ES support. At the moment we are building it with OpenGL ES
on armel and armhf, and with desktop OpenGL on all other
architectures.

currently most arm64 boards are using software rasterization because
their video cards do not support Desktop OpenGL. If we switch to GLES
then most amr64 boards will be able to render using their video
hardware, thus greatly improving speed to the point of being actually
usable for some stuff.
I imagine (but would *love* hard data) that any PCI video card added
to an arm64 machine will probably also support GLES, so they will
still have use.
But one thing is for sure: it's not a decision in which everyone wins,
so we are trying to make a decision on which *most* of our users wins.

The huge majority of the armhf/arm64 cards being put to work today do not
have a pci slot and never will, yet there are 100 of these tiny sbc's
out here doing real work that will never do it thru a pci or pci-e
connector.

Today, on arm stuff, that interface is SPI, and it runs at speeds up to
50 megabaud on the r-pi-3b. Give us a kernel installer that Just Works
using a kernel we've downloaded the src for and built right on these
teeny boards, and give us a 50 megabaud SPI driver, support the mali
video chips these things come with, and a huge bunch of these little
cards will be off to the races.

[Lisandro Damián Nicanor Pérez Meyer]

Is there any possible way to support *BOTH* OpenGL / OpenGLES? Mutually
exclusive from an install POV, but give the end user the choice which to
install? Why should we have one Architecture forced down a path
different to another architecture?

No, I'm afraid there is no way to do that. We did consider it many times, but
is definitely too much work to hack on.

So we need to force an architecture (actually, all of them!) to either one or
the other.

Post by Dmitry Shachnev
Hi all!
The Qt framework can be built either with “desktop” OpenGL, or with OpenGL
ES support. At the moment we are building it with OpenGL ES on armel and
armhf, and with desktop OpenGL on all other architectures

currently most arm64 boards are using software rasterization because
their video cards do not support Desktop OpenGL.

I am not sure that is correct. I certainly don't agree...
There is no special case here. If you have a video card in your ARM64
PC then it is likely the same video card that you have for an AMD64 PC -
i.e. it is an off the shelf PCIe card.
Now it is correct that there is a large number of ARM64 based SoC
solutions out there with an embedded GPU - these are aimed mainly at the
mobile market (but as the computational power in these SoCs increases we
are already seeing that is enough for a lot of peoples 'PC' needs)
I guess what I am trying to say here is the GPU architecture is NOT tied
to the CPU architecture.

- GPU architecture is not tied to the arch: right.
- Qt is tied to either Desktop or GLES: yes

So we need to pick one. The question is then which one will benefit our users
most.

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.

If we switch to GLES then most amr64 boards

will be able to render using their video hardware, thus greatly improving
speed to the point of being actually usable for some stuff.
I imagine (but would *love* hard data) that any PCI video card added to an
arm64 machine will probably also support GLES, so they will still have use.

So <sarcasm>
any PCI video card added to s/amr64/AMD64 machine will probably also
support GLES, so they will still have use.
OK that is true - lets enact this across ALL architectures, but I
suspect that there may be a bit of pushback from the AMD64 heavy graphic
users...
</sarcasm>

No need to use sarcasm. Yes, it's a matter of choice. No one noted yet that
all archs except armel and armhf have Desktop support and not GLES. And this
is because, so far and to the best of our knowledge, that has been the right
thing to do.

So: what's the best outcome for our *current* users? Again, pick only one.

[Dmitry Eremin-Solenikov]

Hello,
пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer

Post by Lisandro Damián Nicanor Pérez Meyer

Is there any possible way to support *BOTH* OpenGL / OpenGLES? Mutually
exclusive from an install POV, but give the end user the choice which to
install? Why should we have one Architecture forced down a path
different to another architecture?

No, I'm afraid there is no way to do that. We did consider it many times, but
is definitely too much work to hack on.
So we need to force an architecture (actually, all of them!) to either one or
the other.

Can you build two packages and allow user to select, which one he wants to
install? Or those packages will be binary incompatible?

Post by Lisandro Damián Nicanor Pérez Meyer

Post by Dmitry Shachnev
Hi all!
The Qt framework can be built either with “desktop” OpenGL, or with
OpenGL
ES support. At the moment we are building it with OpenGL ES on armel and
armhf, and with desktop OpenGL on all other architectures

currently most arm64 boards are using software rasterization because
their video cards do not support Desktop OpenGL.

I am not sure that is correct. I certainly don't agree...
There is no special case here. If you have a video card in your ARM64
PC then it is likely the same video card that you have for an AMD64 PC -
i.e. it is an off the shelf PCIe card.
Now it is correct that there is a large number of ARM64 based SoC
solutions out there with an embedded GPU - these are aimed mainly at the
mobile market (but as the computational power in these SoCs increases we
are already seeing that is enough for a lot of peoples 'PC' needs)
I guess what I am trying to say here is the GPU architecture is NOT tied
to the CPU architecture.

- GPU architecture is not tied to the arch: right.
- Qt is tied to either Desktop or GLES: yes
So we need to pick one. The question is then which one will benefit our users
most.
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.

[Steve McIntyre]

Post by Dmitry Eremin-Solenikov
Hello,
пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer

Post by Lisandro Damián Nicanor Pérez Meyer

Is there any possible way to support *BOTH* OpenGL / OpenGLES? Mutually
exclusive from an install POV, but give the end user the choice which to
install? Why should we have one Architecture forced down a path
different to another architecture?

No, I'm afraid there is no way to do that. We did consider it many times, but
is definitely too much work to hack on.
So we need to force an architecture (actually, all of them!) to either one or
the other.

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.

...

Post by Dmitry Eremin-Solenikov

Post by Lisandro Damián Nicanor Pérez Meyer
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.

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.

[Stefan Monnier]

Post by Steve McIntyre
Yeah - it depends exactly on your background. There's a small (but
growing) set of arm64 desktop users,

Apparently none of them are here, tho.

Post by Steve McIntyre
and it would be unfortunate to cut them off.

But would it? IIUC this proposed change only impacts Qt applications,
and it's not clear whether it would really have a visible impact (if
their graphics card (and drivers) also supports GLES, then presumably
the difference would only be one of performance which may not matter for
those particular Qt applications they use).

IOW, the proposed change will only impact negatively users who have the
following combination:
- Use arm64
- Use Qt
- Use a graphics card whose driver supports GL but not GLES
as well as those users with the following combination:
- Use arm64
- Use Qt
- Use a graphics card whose driver supports both GL and GLES
- Use Qt apps whose performance is noticeably better when using GL than
when using GLES.


Stefan

[Lisandro Damián Nicanor Pérez Meyer]

Andy: explicitly CCing you because I think it answers part of a question you
did but in another part of the thread.
[snip]

Post by Steve McIntyre

Post by Dmitry Eremin-Solenikov
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:

<Loading Image...>

That's almost all of Qt for 5.10 (we have now new submodules, so I need to
update it).

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.

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.

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. And a single mistake could be disastrous.

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.

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?

Post by Steve McIntyre

Post by Dmitry Eremin-Solenikov

Post by Lisandro Damián Nicanor Pérez Meyer
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?

Post by Steve McIntyre
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.

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

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

[Andy Simpkins]

Post by Lisandro Damián Nicanor Pérez Meyer
Andy: explicitly CCing you because I think it answers part of a question you
did but in another part of the thread.
[snip]

Post by Steve McIntyre

Post by Dmitry Eremin-Solenikov
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.
<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

Post by Lisandro Damián Nicanor Pérez Meyer
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

Post by Lisandro Damián Nicanor Pérez Meyer
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

Post by Lisandro Damián Nicanor Pérez Meyer
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

Post by Lisandro Damián Nicanor Pérez Meyer
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...

Post by Lisandro Damián Nicanor Pérez Meyer
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

Post by Lisandro Damián Nicanor Pérez Meyer
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.

Post by Lisandro Damián Nicanor Pérez Meyer
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?

Post by Steve McIntyre

Post by Dmitry Eremin-Solenikov

Post by Lisandro Damián Nicanor Pérez Meyer
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?

Post by Steve McIntyre
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.

Post by Lisandro Damián Nicanor Pérez Meyer
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.

Post by Lisandro Damián Nicanor Pérez Meyer
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

[Sune Vuorela]

Post by Andy Simpkins
BOTH are possible so why dictate only one?

Because it would require two flavours of all users.

/Sune

[bret curtis]

Post by Andy Simpkins

Post by Lisandro Damián Nicanor Pérez Meyer
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.

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

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

[Andy Simpkins]

Post by bret curtis

Post by Andy Simpkins

Post by Lisandro Damián Nicanor Pérez Meyer
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.

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

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

[Gene Heskett]

Post by bret curtis

Post by Andy Simpkins

Post by Lisandro Damián Nicanor Pérez Meyer
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.

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

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.

Post by bret curtis
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.

Post by bret curtis
Cheers,
Bret

[Steve McIntyre]

Post by Gene Heskett
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...

[Gene Heskett]

Post by Steve McIntyre

Post by Gene Heskett
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?

[Raphael Hertzog]

Hello Bret,

Post by bret curtis
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.

Can you back up this claim with some external documentation?
Or at least pointer the appropriate part of the code?

https://github.com/anholt/mesa/wiki/VC4-OpenGL-support says that the
VC4 hardware is a GLES 2.0 renderer and it would seem strange that
the mesa driver for it would not support OpenGL ES.

Cheers,

[bret curtis]

Post by Raphael Hertzog

Post by bret curtis
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.

Can you back up this claim with some external documentation?
Or at least pointer the appropriate part of the code?
https://github.com/anholt/mesa/wiki/VC4-OpenGL-support says that the
VC4 hardware is a GLES 2.0 renderer and it would seem strange that
the mesa driver for it would not support OpenGL ES.

If your hardware supports GLESv2 then by definition your hardware also
supports at least OpenGL 2.1 so please correct me if I'm wrong but all
open-source mesa drivers support both OpenGL and GLES to some degree
and only proprietary drivers support only GLES. If you start only
shipping packages with only GLES support then you're going to begin
dropping packages that only support Desktop GL but would otherwise
work perfectly fine on that architecture. The switch to GLES has the
only benefit of supporting proprietary firmware/software which isn't
exactly DFSG friendly.

The VC4 is not an GLES exclusive renderer, it supports OpenGL up to
2.1 and GLES 2. That information comes from same link I have posted
earlier in this thread that you have just posted now. What I'm saying
is that without the VC4 mesa driver then you're stuck with llvmpipe
making the RPi not very useful as a Desktop and then to only ship
software with GLES only support then excludes other software that
would otherwise work with VC4.

I'm am admittedly biased because I'm also an upstream developer of
such an application (OpenMW) that only works with Desktop GL, that
being said, it is by far not the only one. There are others like
openjk and opentesarena just off the top of my head. From our point of
view, GLES isn't an option. For GLES only devices, we use a shim that
does its best to translate GL2 calls to their equivalent in GLESv2,
but that is really dodgy. From our point of view, the next step is
Vulkan so we only want to target "Desktop" OpenGL and Vulkan for
maximum coverage because it is a waste of time to _also_ support GLES
when Vulkan can be used for both Desktop and Mobile.

Cheers,
Bret

[Lisandro Damián Nicanor Pérez Meyer]

Hi Andy!

Post by Andy Simpkins

Post by Lisandro Damián Nicanor Pérez Meyer
Andy: explicitly CCing you because I think it answers part of a question
you did but in another part of the thread.
[snip]

Post by Steve McIntyre

Post by Dmitry Eremin-Solenikov
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.
<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

Post by Lisandro Damián Nicanor Pérez Meyer
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

Post by Lisandro Damián Nicanor Pérez Meyer
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

Post by Lisandro Damián Nicanor Pérez Meyer
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.

Post by Andy Simpkins
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

Post by Lisandro Damián Nicanor Pérez Meyer
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...

Post by Lisandro Damián Nicanor Pérez Meyer
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

Post by Lisandro Damián Nicanor Pérez Meyer
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.

Post by Andy Simpkins

Post by Lisandro Damián Nicanor Pérez Meyer
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?

Post by Steve McIntyre

Post by Dmitry Eremin-Solenikov

Post by Lisandro Damián Nicanor Pérez Meyer
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?

Post by Steve McIntyre
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.

Post by Andy Simpkins
<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>
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.
Well, I could invite you to join us maintaining Qt and it's ecosystem ;-)

Post by Andy Simpkins
* 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
* 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.

Post by Andy Simpkins

Post by Lisandro Damián Nicanor Pérez Meyer
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.

Post by Lisandro Damián Nicanor Pérez Meyer
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 :-)

Post by Andy Simpkins
I would like to see OpenGLES available on all architectures

Me too.

Post by Andy Simpkins
I would like to see OpenGL available on all architectures

Me too.

Post by Andy Simpkins
I think that there is a relatively painless method to achieve this

That's *exactly* where we disagree.

Post by Andy Simpkins
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.

[Wookey]

Post by Dmitry Eremin-Solenikov
Hello,

Post by Lisandro Damián Nicanor Pérez Meyer
- Qt is tied to either Desktop or GLES: yes
So we need to pick one. The question is then which one will benefit our users
most.
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.

My main desktop is now an arm64 machine with an nvidia PCI graphics
card. These are fairly new (and currently expensive), but I have
reason to believe there is more of this sort of thing coming, and
laptop-format machines.

I need to investigate this further, but changing from GL to GLES just
at the moment where desktop hardware starts to make inroads could be a
big own goal on arm64. I recall Linaro doing some work on this back
when it started (to make it easier to switch between GL and
GLES). Possibly that work never actually got done, just talked out.

Wookey

[Lisandro Damián Nicanor Pérez Meyer]

Hi Wookey!

Post by Wookey

Post by Dmitry Eremin-Solenikov
Hello,

Post by Lisandro Damián Nicanor Pérez Meyer
- Qt is tied to either Desktop or GLES: yes
So we need to pick one. The question is then which one will benefit our
users most.
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.

My main desktop is now an arm64 machine with an nvidia PCI graphics
card. These are fairly new (and currently expensive), but I have
reason to believe there is more of this sort of thing coming, and
laptop-format machines.

Well, that's at very least an interesting data point. So yes, they exist, but
they are new and expensive. Can I assume that this means most of our arm64
users do not yet get to them?

Post by Wookey
I need to investigate this further, but changing from GL to GLES just
at the moment where desktop hardware starts to make inroads could be a
big own goal on arm64.

That's *exactly* what I have been reading since I filled the bug I mentioned
before in... 2015. So far all I could see are embedded boards.

But hey, we can change it now and always go back in the future if arm64
motherboards become ubiquitous.

Post by Wookey
I recall Linaro doing some work on this back
when it started (to make it easier to switch between GL and
GLES). Possibly that work never actually got done, just talked out.

It would really help, indeed.

[Gene Heskett]

On Thursday 22 November 2018 19:17:29 Lisandro Damián Nicanor Pérez Meyer

Post by Lisandro Damián Nicanor Pérez Meyer

Is there any possible way to support *BOTH* OpenGL / OpenGLES?
Mutually exclusive from an install POV, but give the end user the
choice which to install? Why should we have one Architecture forced
down a path different to another architecture?

No, I'm afraid there is no way to do that. We did consider it many
times, but is definitely too much work to hack on.
So we need to force an architecture (actually, all of them!) to either
one or the other.

El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev

Post by Dmitry Shachnev
Hi all!
The Qt framework can be built either with “desktop” OpenGL, or
with OpenGL
ES support. At the moment we are building it with OpenGL ES on
armel and armhf, and with desktop OpenGL on all other
architectures

currently most arm64 boards are using software rasterization
because their video cards do not support Desktop OpenGL.

I am not sure that is correct. I certainly don't agree...
There is no special case here. If you have a video card in your
ARM64 PC then it is likely the same video card that you have for an
AMD64 PC - i.e. it is an off the shelf PCIe card.
Now it is correct that there is a large number of ARM64 based SoC
solutions out there with an embedded GPU - these are aimed mainly at
the mobile market (but as the computational power in these SoCs
increases we are already seeing that is enough for a lot of peoples
'PC' needs)
I guess what I am trying to say here is the GPU architecture is NOT
tied to the CPU architecture.

- GPU architecture is not tied to the arch: right.
- Qt is tied to either Desktop or GLES: yes
So we need to pick one. The question is then which one will benefit
our users most.
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.

If we switch to GLES then most amr64 boards

will be able to render using their video hardware, thus greatly
improving speed to the point of being actually usable for some
stuff.
I imagine (but would *love* hard data) that any PCI video card
added to an arm64 machine will probably also support GLES, so they
will still have use.

So <sarcasm>
any PCI video card added to s/amr64/AMD64 machine will probably also
support GLES, so they will still have use.
OK that is true - lets enact this across ALL architectures, but I
suspect that there may be a bit of pushback from the AMD64 heavy
graphic users...
</sarcasm>

No need to use sarcasm. Yes, it's a matter of choice. No one noted yet
that all archs except armel and armhf have Desktop support and not
GLES. And this is because, so far and to the best of our knowledge,
that has been the right thing to do.
So: what's the best outcome for our *current* users? Again, pick only one.

And that is something you probably won't have the power to do, because
the huge majority of these things are being designed by engineers
looking for the most bang for the buck, and coming up thru the schools
all run by M$ or Apple. Linux is simply not even on their radar.

But, what you do do, makes or breaks their success in doing things that
only linux can do best. Windows has no possibility of a realtime kernel,
linux does, has several choices depending on just how realtime you want.
Windows hasn't figured out what this thing called SPI is yet that I've
heard about.

One LinuxCNC driver has SPI figured out, and you can find it in the
LinuxCNC srcs as rpspi.c, but the professor that wrote it, with me and
my pi 3b, driving a 70 yo Sheldon 11x36 Lathe as lab rats to test it,
also wrote it so it only runs on an r-pi-3b. Fixing it to build and run
on another platform with a different, probably broadcom gpio driver
headers would be a very welcome addition to the arm toolbox as a whole,
but is beyond my well aged wet ram's ability at my age.

Now, I'll go play Al Capp from the comic strip and shaddup.

[Dmitry Shachnev]

I do understand that there would be a lot of effort required to support OGL
and OGLES but as you have already pointed out "you are doing this already"
because OGL is provided for all platforms except armel & armhf which have
OGLES - that means you are already tracking changes for *BOTH* ecosystems.
Having OGL & OGLES available on the same architecture would be setup
involved in creating two package streams, but once done the actual build
process is automated. Yes there are now twice as many resulting sets of
binaries for this layer, but it is reasonable to assume that functional
test of each strand can be split across the testing for all architectures
(where not automated), so the increased workload again shouldn't differ by
much (just the supporting of the automation).
I am sure my view is nieve and a little too simplistic...

Please keep in mind that not only we (the Qt maintainers) should maintain two
sets of packages, but also maintainers of third party Qt libraries and
applications.

Even in Ubuntu where the core developers can upload any package, this setup
did not work fine (they tried to maintain twin -gles packages for x86 for the
Ubuntu touch port to these architectures).

As of today there are considerably more 'mobile' arm devices.  I suspect
that this will continue because they are lower cost mass market products.
Full 'desktop' on arm64 has felt very close for the last few years, but
hardware isn't there just yet.
There are some quite big server SoCs out there, but the desktop & laptop
world isn't well serviced.
[...]
If you want to look at sheer numbers then OGLES will 'win' hands down, but
my gut tells me that long term excluding OGL from the arm64 architecture
would be the wrong decision

Thanks, this information is useful!

I would still like to know if the upcoming arm64 desktop devices have any
problems working with OpenGL ES.

Anyway, the decision we are making now is not permanent, we can always
revisit it in a few years like we are now revisiting the decision to stick
with desktop OpenGL.

--
Dmitry Shachnev

[Marcin Juszkiewicz]

Post by Dmitry Shachnev
I would still like to know if the upcoming arm64 desktop devices have
any problems working with OpenGL ES.

Arm64 desktop systems use Radeon or NVidia cards with same opensource
drivers as x86-64 systems. So you can check how it goes with OpenGL ES
on your amd64 desktop.

[Dmitry Shachnev]

Post by Marcin Juszkiewicz

Post by Dmitry Shachnev
I would still like to know if the upcoming arm64 desktop devices have
any problems working with OpenGL ES.

Arm64 desktop systems use Radeon or NVidia cards with same opensource
drivers as x86-64 systems. So you can check how it goes with OpenGL ES
on your amd64 desktop.

I have an embedded Intel card right now :)

What is the status of OpenGL ES support with these drivers?

--
Dmitry Shachnev

[p***@gmail.com]

Just chiming in here as package maintainer of an effected package, OpenMW
and also an upstream developer of said software, along with contributor to
OpenSceneGraph.

Here are some related open bugs involving Qt and GLESv2 and arm*:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850021
^-- RM: openmw [armhf] -- RoQA; needs OSG built against libGL

The editor of OpenMW uses osgQt, which is provided by OSG. OSG has to pick,
Desktop GL or GLESv2 it can't be both and because GLESv2 was forced on
armhf and armel for Qt, then OSG had to do the same because of one of their
plugins (now deprecated in OSG-3.6) links against Qt. The result is that
OpenMW can't be built/shipped on armhf/armel on Debian because it only
supports OpenGL 2.0 fixed function pipeline.

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.

Another related bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852423
^-- revert all arm* changes to OSG and drop osgQt support in order to
compile against libGL (Desktop GL). A radical solution, but it would allow
for applications like OpenMW to run (but not the editor).

My merge-request on Salsa was already merged in for OSG-3.6 that does this,
since osgQt is no longer shipped with OSG, we no longer needed Qt nor the
GLESv1/2 support.
https://salsa.debian.org/openscenegraph-team/openscenegraph-3.6/merge_requests/1


I beg you, please either reverse the GLES decision in Qt or provide two
separate packages for GL or GLES support.

Cheers,
Bret

[Lisandro Damián Nicanor Pérez Meyer]

Hi Bret!

Post by p***@gmail.com
Just chiming in here as package maintainer of an effected package, OpenMW
and also an upstream developer of said software, along with contributor to
OpenSceneGraph.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850021
^-- RM: openmw [armhf] -- RoQA; needs OSG built against libGL

[snip]

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

Post by p***@gmail.com
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?

[snip]

Post by p***@gmail.com
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.

[bret curtis]

Hello Lisandro!

Post by Lisandro Damián Nicanor Pérez Meyer
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.

Post by Lisandro Damián Nicanor Pérez Meyer

Post by p***@gmail.com
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.

Post by Lisandro Damián Nicanor Pérez Meyer

Post by p***@gmail.com
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

[Lisandro Damián Nicanor Pérez Meyer]

Post by bret curtis
Hello Lisandro!

Post by Lisandro Damián Nicanor Pérez Meyer
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.

Post by Lisandro Damián Nicanor Pérez Meyer

Post by p***@gmail.com
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.

Post by bret curtis
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.

Post by bret curtis
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
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.

Post by Lisandro Damián Nicanor Pérez Meyer

Post by p***@gmail.com
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.

[bret curtis]

Post by Lisandro Damián Nicanor Pérez Meyer

Post by 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

[Scott Kitterman]

Post by bret curtis

Post by Lisandro Damián Nicanor Pérez Meyer

Post by 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]
- 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

[bret curtis]

Hey Scott,

Post by Scott Kitterman
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

[Raphael Hertzog]

Hello,

Post by bret curtis
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]

That's a different claim to what you made in a former message.

Post by bret curtis
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?

Wrong question. Maybe it makes sense for you at the application level for
the application that are hooking into OpenGL directly. But we are speaking
of having decent graphical performances for all Qt based-applications on
hardware that only support GLES and not Desktop OpenGL.

That kind of hardware does exist now and people who try to use Debian
on it will be disappointed because even LXQt will feel sluggish on them.

This is not a easy decision to make, in the ideal world we would support
both Qt stack but this is not realistic and we have to make a choice.

So basically there are two choices:

1/ 99% of users get decent performance with 98% of the Qt-based
applications, but 2% of the applications will not work because
they only support Qt with Desktop OpenGL or have some other
incompatibility (2% is probably over-inflated, but the order
is roughly correct and enough to get my point)

2/ 50% of the arm64 users have sluggish/unusable KDE/Qt-based applications
and 50% of the users have the best performance with their Qt-based
applications and those can also benefit from the 2% of the applications
that would not be available otherwise. Those applications can be fixed
to build with either OpenGL or GLES.
(and here I'm saying 50% are losing but with the hardware available
right now, it's certainly more than 50%... most arm64 boards are
tailored for the embedded/mobile market)

In my opinion, Debian as a universal operating system should make choice
#1 so that most hardware bought by most users work well with most
applications. Getting 2% more applications or 20% more performance on the
applications at the cost of 50% of the users not being able to use their
hardware with decent performance is not the correct choice.

Cheers,

PS: None of the figures are accurate but I believe that they are not
misleading and are enough to understand my reasoning. For example,
I have no idea how much faster Qt with Desktop OpenGL vs Qt with GLES can
be.

[bret curtis]

Hi!

Post by Raphael Hertzog

Post by bret curtis
What applications does Debian have in its repo that only support GLES?

Wrong question. Maybe it makes sense for you at the application level for
the application that are hooking into OpenGL directly. But we are speaking
of having decent graphical performances for all Qt based-applications on
hardware that only support GLES and not Desktop OpenGL.

This is the wrong assumption because if your hardware supports GLES,
then it also supports GL. It is only the proprietary
module/driver/firmware that exposes the GLES only. Take a look at all
the mesa drivers, they all support OpenGL and GLES.

Post by Raphael Hertzog
That kind of hardware does exist now and people who try to use Debian
on it will be disappointed because even LXQt will feel sluggish on them.

The hardware that supports GLES also supports OpenGL because GLES is a
subset of OpenGL. I find it very hard to believe that the hardware
somehow performs differently, if anything, the difference probably
comes from the proprietary module/driver/firmware.

Post by Raphael Hertzog
This is not a easy decision to make, in the ideal world we would support
both Qt stack but this is not realistic and we have to make a choice.

It is not an easy decision to make. I grant you that.

Post by Raphael Hertzog
In my opinion, Debian as a universal operating system should make choice
#1 so that most hardware bought by most users work well with most
applications. Getting 2% more applications or 20% more performance on the
applications at the cost of 50% of the users not being able to use their
hardware with decent performance is not the correct choice.

I find it hard to believe that Debian, as a universal operating
system, would sacrifice software and freedom because some 3rd party
software only supports GLES or that they implemented OpenGL poorly.

I do however understand that there is a time/effort trade off here. Qt
supports both already but only one or the other and currently not both
at the same time. My only question then becomes, what is going to
happen when support for Vulkan lands. Are we going to have the same
discussion? The work will eventually have to be done.

Cheers,
Bret

[Ian Campbell]

Post by bret curtis
The hardware that supports GLES also supports OpenGL because GLES is
a subset of OpenGL.

I'm confused by this inference. If GLES is a subset of OpenGL then
surely hardware which claims to implement GLES is at liberty to only
implement that subset and would therefore not necessarily support
OpenGL.

Ian.

[bret curtis]

Hello Ian,

Post by Ian Campbell

Post by bret curtis
The hardware that supports GLES also supports OpenGL because GLES is
a subset of OpenGL.

I'm confused by this inference. If GLES is a subset of OpenGL then
surely hardware which claims to implement GLES is at liberty to only
implement that subset and would therefore not necessarily support
OpenGL.
Ian.

I believe this is a purely a driver/firmware distinction. So whoever
implements this is at liberty to do whatever they want so long as the
hardware supports it.

Meaning that if something advertises GLESv2 support then it has, at
least, OpenGL 2.0 support in hardware because without that, they
couldn't have supported GLESv1.

GLES1.1 is fixed-function pipeline that is compatible with OpenGL 2.0,
you're not going to create hardware to support GLES1.1 that doesn't
also support at least OpenGL 2.0

GLESv2 is another beast, it dropped fixed-function pipeline because
that was the spec, but it is still a software implementation and
doesn't mean that it no longer exists in hardware.

Take for example the Nvidia Tegra:
https://opengles.gpuinfo.org/displayreport.php?id=690 <-- SHIELD
Android TV which happens to be a Tegra SoC supports OpenGL ES 3.2
https://opengl.gpuinfo.org/displayreport.php?id=2377 <-- Tegra as
integrated with CPU (nvgpu), supports OpenGL 4.6.0

Similar (if not the same?) hardware, running aarch64, the only real
difference is the driver.

That being said, I would love to hear from someone who actually makes
these things to comment. It is entirely possible that there is a chip
out there that supports GLES 3.2 and only that in hardware. I would be
amazed but I'm reluctant to ever use the words never and ever. So far,
the hardware that supports that are[1]:

Adreno 420 and newer
AMD GCN-architecture
Intel HD Graphics Skylake and higher
Mali-T760 and newer
Nvidia GeForce 400 series (Fermi)

As I said, I would be amazed if these GPUs didn't support some minimal
version OpenGL in hardware. As I said elsewhere, most free and
open-source drivers (mesa) support both some version of GLES along
with some version of GL. [2]

Cheers,
Bret


[1] https://en.wikipedia.org/wiki/OpenGL_ES#OpenGL_ES_3.2_2
[2] https://mesamatrix.net/

[Alan Corey]

Try glxgears and es2gears on few different platforms. On a Pi 3b
glxgears runs at about 45 FPS, es2gears slightly lower. On my Rock64
it's in the hundreds of FPS but that's Mali. Look at omxplayer, full
screen HD video while the CPU idles (on a Pi). The GPU is more
capable than the CPU. You can do software-emulated OpenGL on
anything, the question is how efficient it is.

Post by bret curtis
Hello Ian,

Post by Ian Campbell

Post by bret curtis
The hardware that supports GLES also supports OpenGL because GLES is
a subset of OpenGL.

I'm confused by this inference. If GLES is a subset of OpenGL then
surely hardware which claims to implement GLES is at liberty to only
implement that subset and would therefore not necessarily support
OpenGL.
Ian.

I believe this is a purely a driver/firmware distinction. So whoever
implements this is at liberty to do whatever they want so long as the
hardware supports it.
Meaning that if something advertises GLESv2 support then it has, at
least, OpenGL 2.0 support in hardware because without that, they
couldn't have supported GLESv1.
GLES1.1 is fixed-function pipeline that is compatible with OpenGL 2.0,
you're not going to create hardware to support GLES1.1 that doesn't
also support at least OpenGL 2.0
GLESv2 is another beast, it dropped fixed-function pipeline because
that was the spec, but it is still a software implementation and
doesn't mean that it no longer exists in hardware.
https://opengles.gpuinfo.org/displayreport.php?id=690 <-- SHIELD
Android TV which happens to be a Tegra SoC supports OpenGL ES 3.2
https://opengl.gpuinfo.org/displayreport.php?id=2377 <-- Tegra as
integrated with CPU (nvgpu), supports OpenGL 4.6.0
Similar (if not the same?) hardware, running aarch64, the only real
difference is the driver.
That being said, I would love to hear from someone who actually makes
these things to comment. It is entirely possible that there is a chip
out there that supports GLES 3.2 and only that in hardware. I would be
amazed but I'm reluctant to ever use the words never and ever. So far,
Adreno 420 and newer
AMD GCN-architecture
Intel HD Graphics Skylake and higher
Mali-T760 and newer
Nvidia GeForce 400 series (Fermi)
As I said, I would be amazed if these GPUs didn't support some minimal
version OpenGL in hardware. As I said elsewhere, most free and
open-source drivers (mesa) support both some version of GLES along
with some version of GL. [2]
Cheers,
Bret
[1] https://en.wikipedia.org/wiki/OpenGL_ES#OpenGL_ES_3.2_2
[2] https://mesamatrix.net/

[Gene Heskett]

Post by bret curtis

Post by Lisandro Damián Nicanor Pérez Meyer

Post by 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]
- 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.

[Lisandro Damián Nicanor Pérez Meyer]

Post by Dmitry Shachnev

Post by Marcin Juszkiewicz

Post by Dmitry Shachnev
I would still like to know if the upcoming arm64 desktop devices have
any problems working with OpenGL ES.

Arm64 desktop systems use Radeon or NVidia cards with same opensource
drivers as x86-64 systems. So you can check how it goes with OpenGL ES
on your amd64 desktop.

I have an embedded Intel card right now :)

Same here, 10 years old machine with an embedded Intel video card. I don't
think I can expect it to work with GLES.

[Lisandro Damián Nicanor Pérez Meyer]

Hi everyone!

We the Qt maintainers have reached a decision with respect to this topic. We
reached debian-devel in order to get an idea of what other fellow Debian users
and developers think of this subject. We would *really* like to thank you all
for chiming in and discussing this in quite a nice way. Yes, most of us have
strong positions, but even then the discussion was both civil and fruitful. So
again, thanks to you all!

It seems now clear that the general consensus seems to expect:

= Qt available for both Desktop and ES OpenGL flavours

As we tried hard to explain this is really not easy nor even supported by
upstream. But of course, if someone thinks [s]he wants to take the effort then
[s]he's more than welcomed to joining the team. You will certainly need C++
library packaging skills and a *whole lot* of free time and build power. Due
to the nature of this change, if the goal is achieved, it will be certainly
targeted for Buster+1.

= If no change is possible, keep arm64 with Desktop OpenGL support

That seems to be what most of you want, and to say the truth, the easiest for
us: we just keep status quo, no transition needed. We just package the next
point release, check for bugs and mostly be done for Buster. So this is the
approach we will take.

Both Dmitry and I just learned that the RPI has the VC4 driver which enables
it to do hardware acceleration for Desktop OpenGL, we must admit that this is
a game changer in many ways, even if we are talking on just one board (but
quite an ubiquitous one). People wanting Qt+GLES on arm64 can always use
Ubuntu.

For the Qt side of the Qt/KDE Team,

Lisandro

People reading the bug: please see

<https://lists.debian.org/debian-devel/2018/11/msg00457.html>

[Paul Wise]

Post by Lisandro Damián Nicanor Pérez Meyer
Both Dmitry and I just learned that the RPI has the VC4 driver which enables
it to do hardware acceleration for Desktop OpenGL, we must admit that this is
a game changer in many ways, even if we are talking on just one board (but
quite an ubiquitous one).

I expect this also applies to any driver in (or soon to be in) mesa,
including freedreno (Qualcomm), panfrost (Mali), lima (Mali), Etnaviv
(Vivante), Tegra etc. Drivers only supporting GLES seems to be a
something that happens only with the proprietary drivers. I don't have
any ARM devices with GPUs to be able to test this though.

[Gene Heskett]

Post by Paul Wise

Post by Lisandro Damián Nicanor Pérez Meyer
Both Dmitry and I just learned that the RPI has the VC4 driver which
enables it to do hardware acceleration for Desktop OpenGL, we must
admit that this is a game changer in many ways, even if we are
talking on just one board (but quite an ubiquitous one).

I expect this also applies to any driver in (or soon to be in) mesa,
including freedreno (Qualcomm), panfrost (Mali),

And in what repo might I find this panfrost thingy for stretch?

Post by Paul Wise
lima (Mali),

Or this one?

Post by Paul Wise
Etnaviv
(Vivante), Tegra etc. Drivers only supporting GLES seems to be a
something that happens only with the proprietary drivers. I don't have
any ARM devices with GPUs to be able to test this though.

[Paul Wise]

Post by Gene Heskett
And in what repo might I find this panfrost thingy for stretch?

Post by Paul Wise
lima (Mali),

Or this one?

Neither of these projects have a mainline mesa driver yet, they are
both are in the reverse engineering and driver development phase.

https://gitlab.freedesktop.org/panfrost
https://gitlab.freedesktop.org/lima

Latest post from the panfrost blog:

https://rosenzweig.io/blog/a-panfrostian-october.html

[Stefan Monnier]

Post by Paul Wise

Post by Lisandro Damián Nicanor Pérez Meyer
Both Dmitry and I just learned that the RPI has the VC4 driver which enables
it to do hardware acceleration for Desktop OpenGL, we must admit that this is
a game changer in many ways, even if we are talking on just one board (but
quite an ubiquitous one).

I expect this also applies to any driver in (or soon to be in) mesa,
including freedreno (Qualcomm), panfrost (Mali), lima (Mali), Etnaviv
(Vivante), Tegra etc. Drivers only supporting GLES seems to be a
something that happens only with the proprietary drivers.

So, IIUC this means that armhf's Qt will likely want to switch to OpenGL
in the (hopefully near) future (when the use of proprietary drivers on
armhf boards becomes rarely necessary thanks to the availability of
lima/...)?


Stefan

[Raphael Hertzog]

Hello Lisandro,

TLDR: thank you for starting this discussion, it was required as it's not
an easy decision to take as there is no realistic perfect solution, but I
believe you took the wrong decision. Please consider deferring the
decision to the technical committe by seeking his advice (point 6.1.3
of the constitution https://www.debian.org/devel/constitution.en.html#item-6).

Post by Lisandro Damián Nicanor Pérez Meyer
= Qt available for both Desktop and ES OpenGL flavours
= If no change is possible, keep arm64 with Desktop OpenGL support

I'm not pleased with how this discussion was handled. First of all,
you did not leave enough time for all stakeholders to participate in
the discussion (started on November 22th, closed November 25th, 3 days,
that's not a reasonable timeframe in particular when 2 of the 3 days
were in the week-end). I was aware of the discussion but did not
had the time to chime in, yet I was the person who re-opened the bug
#881333 in the first place.

I also invited someone else who is working on a concrete project involving
Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
now but he also did not have the time to contribute to the discussion.

Then I have read the whole discussion and I don't have the feeling that
any consensus has been reached. It was largely driven by Andy Simpkins
who explained his "gut feeling" as a tinkerer of arm* boards/devices and
Bret Curtis who contributes to some applications with very specific OpenGL
needs. While I value their contribution to the discussion, they both
represent very specific classes of users.

What I remember from this discussion is that the Windows build of Qt
use GLES 2 by default. It would have been interesting to find out the
rationale for this... because maybe the right decision for us would be
to switch to GLES 2 by default as well (on all architectures as jcristau
suggested). Someone else who likely also tried to ensure Qt for Windows is
usable on most hardware made that choice.

We got confirmation from many persons that almost all cards benefitting
from Desktop OpenGL would also work with OpenGL ES. So in terms of
hardware support, picking OpenGL ES is the right choice. In terms of
sofware support, it looks like that Desktop OpenGL is better as there
are a few applications that only work with Desktop OpenGL.

Software can be fixed/improved to also work with OpenGL ES. However
hardware, once bought, cannot be fixed to support Desktop OpenGL
when it has been designed for OpenGL ES only.

When taking all this into account, I believe that the right solution is
to use OpenGL ES on all architectures. This will provide the required
incentives for application developers who stick only to Desktop OpenGL
to support OpenGL ES (even it it's at the cost of using some intermediary
layer like https://github.com/p3/regal) and would maximize hardware
support on all architectures.

That said, I'm fine with a decision to change only arm64 since that's
an architecture were devices that support only OpenGL ES are in the
majority.

This is not a easy decision to make but we have a dedicated body to help
maintainers find the best technical decision when there are pros/cons
in both solutions, it's called the technical committee. Please consider
seeking their advice before taking your decision.

Post by Lisandro Damián Nicanor Pérez Meyer
Both Dmitry and I just learned that the RPI has the VC4 driver which enables
it to do hardware acceleration for Desktop OpenGL, we must admit that this is
a game changer in many ways, even if we are talking on just one board (but
quite an ubiquitous one). People wanting Qt+GLES on arm64 can always use
Ubuntu.

I don't see why this affects the decision in any way. AFAIK the VC4 driver
also enables hardware acceleration for OpenGL ES. And this is only
relevant for the RPI3 which is the only arm64 hardware.

Bret Curtis clearly explained that we do get good performances on older
RPI (armhf-based) precisely because of the VC4 driver being able to
leverage OpenGL ES too.

Cheers,

[Jonas Smedegaard]

Quoting Raphael Hertzog (2018-11-26 12:37:57)

Post by Raphael Hertzog
Software can be fixed/improved to also work with OpenGL ES. However
hardware, once bought, cannot be fixed to support Desktop OpenGL when
it has been designed for OpenGL ES only.

Is some _hardware_ really "designed for OpenGL ES only"?

I guess you mean that some hardware is only supported by non-free
firmware/software hardcoded which is designed for OpenGL ES only".


- Jonas

[Riku Voipio]

Post by Raphael Hertzog
were in the week-end). I was aware of the discussion but did not
had the time to chime in, yet I was the person who re-opened the bug
#881333 in the first place.
I also invited someone else who is working on a concrete project involving
Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
now but he also did not have the time to contribute to the discussion.
Software can be fixed/improved to also work with OpenGL ES. However
hardware, once bought, cannot be fixed to support Desktop OpenGL
when it has been designed for OpenGL ES only.

Reading from #881333 you mean Gemini PDA. It comes with Mediatek X27,
featuring Mali-T880. The hardware is not OpenGL ES only .. the
propiertary driver is. Mesa-based panfrost driver should support both
OpenGL and OpenGL ES:

https://gitlab.freedesktop.org/panfrost

The open source driver is of course not ready... ...but neither is
Debian ES 2.0. In the long run, making the driver ready is time better
spent than time spent trying to make Debian more friendly to a class
of propiertary drivers.

Riku

[Lisandro Damián Nicanor Pérez Meyer]

Post by Raphael Hertzog
Hello Lisandro,
TLDR: thank you for starting this discussion, it was required as it's not
an easy decision to take as there is no realistic perfect solution,

Our (team-wide) pleasure. This is something we have been digging since 2015.

Post by Raphael Hertzog
but I
believe you took the wrong decision. Please consider deferring the
decision to the technical committe by seeking his advice (point 6.1.3
of the constitution
https://www.debian.org/devel/constitution.en.html#item-6).

Will "kind of" do. Read below.

Post by Raphael Hertzog

Post by Lisandro Damián Nicanor Pérez Meyer
= Qt available for both Desktop and ES OpenGL flavours
= If no change is possible, keep arm64 with Desktop OpenGL support

I'm not pleased with how this discussion was handled. First of all,
you did not leave enough time for all stakeholders to participate in
the discussion (started on November 22th, closed November 25th, 3 days,
that's not a reasonable timeframe in particular when 2 of the 3 days
were in the week-end).

My most sincere apologies if our timeframe do not fit yours.

Now, wrt the decision: clearly the situation is very complex, involving many
different kinds of arm64 devices, drivers, libraries et all. People involved
have different opinions. We so far have been the proxy between them, be it on
bugs, IRC or whatever other channels our users have to contact us. We prefer
not to be this proxy anymore (again, read below).

Besides we (Qt's team) have just learned that the Desktop/ES support is not
tied to the hardware but to the driver. That's a particularly interesting
point.

So:

To quote my original mail, the "Qt available for both Desktop and ES OpenGL
flavours" point remains unchanged: if someone wants to make it happen [s]he
must join the team and support it from the inside. Remember there are little
chances for this to happen in time for Buster.

For the second point, "If no change is possible, keep arm64 with Desktop
OpenGL support", we have this position: we will keep the status quo, deferring
users who want GLES support to Ubuntu.

*But* we are open to change this for any arch (read it: support either one or
the other technology) as long as the decision is taken by the technical
committee. As I wrote before, we will keep the status quo, so if anyone is
interested in any change feel free to contact the TC.

Regards, Lisandro.