Bug#881333: qtbase5-dev: Rebuild qtbase with OpenGL ES support for arm64

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Bug#881333: qtbase5-dev: Rebuild qtbase with OpenGL ES support for arm64

Rohan Garg-3
Package: qtbase5-dev
Version: 5.9.1+dfsg-2+16.04+xenial+build25
Severity: normal

Dear Maintainer,
ARM64 Devices such as the ODROID C2, Pinebook, Pineboard only support
OpenGL ES 2.0 acceleration. However, qtbase seems to be built with
OpenGL acceleratio on ARM64 leading to unaccelerated apps such as
Plasma's new systemsettings.

Could you please rebuild qtbase with OpenGL ES acceleration on ARM64
instead so as to provide a better user experience on these devices?

Cheers
Rohan Garg

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-38-generic (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qtbase5-dev depends on:
ii  libgl1-mesa-dev [libgl-dev]    17.0.7-0ubuntu0.16.04.2
ii  libglu1-mesa-dev [libglu-dev]  9.0.0-2.1
ii  libqt5concurrent5              5.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5core5a                   5.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5dbus5                    5.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5gui5                     5.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5network5                 5.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5printsupport5            5.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5sql5                     5.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5test5                    5.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5widgets5                 5.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5xml5                     5.9.1+dfsg-2+16.04+xenial+build25
ii  libxext-dev                    2:1.3.3-1
ii  qt5-qmake                      5.9.1+dfsg-2+16.04+xenial+build25
ii  qtbase5-dev-tools              5.9.1+dfsg-2+16.04+xenial+build25
ii  qtchooser                      63-g13a3d08-1+16.04+xenial+build15

Versions of packages qtbase5-dev recommends:
pn  libqt5opengl5-dev  <none>

Versions of packages qtbase5-dev suggests:
pn  default-libmysqlclient-dev  <none>
pn  firebird-dev                <none>
ii  libegl1-mesa-dev            17.0.7-0ubuntu0.16.04.2
ii  libgl1-mesa-dev             17.0.7-0ubuntu0.16.04.2
pn  libpq-dev                   <none>
ii  libsqlite3-dev              3.11.0-1ubuntu1
pn  unixodbc-dev                <none>

-- no debconf information

Reply | Threaded
Open this post in threaded view
|

Bug#881333: qtbase5-dev: Rebuild qtbase with OpenGL ES support for arm64

Lisandro Damián Nicanor Pérez Meyer-2
On viernes, 10 de noviembre de 2017 13:58:51 -03 Rohan Garg wrote:

> Package: qtbase5-dev
> Version: 5.9.1+dfsg-2+16.04+xenial+build25
> Severity: normal
>
> Dear Maintainer,
> ARM64 Devices such as the ODROID C2, Pinebook, Pineboard only support
> OpenGL ES 2.0 acceleration. However, qtbase seems to be built with
> OpenGL acceleratio on ARM64 leading to unaccelerated apps such as
> Plasma's new systemsettings.
>
> Could you please rebuild qtbase with OpenGL ES acceleration on ARM64
> instead so as to provide a better user experience on these devices?
As discussed on IRC, it means beaking ABI and also arm64 is likely to have
DesktopOpenGL support as per https://nullr0ute.com/2017/09/the-state-of-open-source-accelerated-graphics-on-arm-devices/

So for the moment is a non-go.


--
Dadme voto electrónico y con una terminal os haré presidente.
  el.machi

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: qtbase5-dev: Rebuild qtbase with OpenGL ES support for arm64

Raphael Hertzog-3
Control: reopen -1 [hidden email]

Hello,

On Mon, 13 Nov 2017, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Could you please rebuild qtbase with OpenGL ES acceleration on ARM64
> > instead so as to provide a better user experience on these devices?
>
> As discussed on IRC, it means beaking ABI and also arm64 is likely to
> have DesktopOpenGL support as per
> https://nullr0ute.com/2017/09/the-state-of-open-source-accelerated-graphics-on-arm-devices/
>
> So for the moment is a non-go.

I asked on IRC and mitya57 told me that we can revisit this decision.

I'm not an expert in this topic but in Kali we have quite some experience
in providing Kali images for specific ARM devices. Right now we are
working on getting Kali working in the Gemini PDA and this bug is a
blocker:
https://store.planetcom.co.uk/products/gemini-pda-1

I asked a few questions to the person working on this project. My questions
were those:
> Can we reasonably say that most arm64 boards have OpenGL ES but no
> regular OpenGL? Can you provide a somewhat up-to-date list to back up
> this fact?
> Can a QT compiled for OpenGL ES still benefit from some hardware
> acceleration on a board with full OpenGL support?

Here's the answer that I got from Re4son:

> I haven't come across any arm64 chipset with an OpenGL enabled GPU apart
> from 2 NVIDIA's CUDA based platforms. I've heard about the idea but they
> were merely academic and nothing seems to have come out of it.  Quite
> the opposite - everybody seem to toy with the idea of moving to Vulkan
> rather than GL.
> The core principle is to provide packages that match the GPU's attached
> to the architecture and according to the following stats, all but 2 of
> the GPU's attached to arm support only GLES:
>
> https://www.khronos.org/conformance/adopters/conformant-products/opengles
> https://www.khronos.org/conformance/adopters/conformant-products/opengl
>
> I haven't experimented with it, but according to the specifications
> OpenGL GPU's are capable of running GLES applications albeit not to the
> full potential of the hardware. The only scenario where I could see that
> being an issue is when someone puts a GL enabled GPU in an arm64 server
> and I cannot imagine that they are craving top shelf 3D acceleration of
> their qt applications.
> More objectively, Ubuntu did that switch two years ago and there have
> been no issues reported in launchpad as a result of it.
He wanted to get some confirmation of all this but he did not manage to
get any response from the experts he tried to contact.

Based on all this, it seems to me that we would better served by using OpenGL
ES on arm64. If we don't do this, we should likely be providing conflicting
packages to support both QT with OpenGL and QT with OpenGL ES but I can see
that becoming rather hard to handle.

And the fact that Ubuntu made the switch is reassuring: it can be done and it's
likely the most useful choice right now. I'm ccing the Ubuntu developer who
made the switch in case he can add something useful to this discussion (the
change happened in qtbase-opensource-src (5.5.1+dfsg-17ubuntu2~2 in yakkety
in 2016).

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

signature.asc (535 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: qtbase5-dev: Rebuild qtbase with OpenGL ES support for arm64

Lisandro Damián Nicanor Pérez Meyer-2
Hi everybody!

El martes, 25 de septiembre de 2018 11:07:31 -03 Raphael Hertzog escribió:

> Control: reopen -1 [hidden email]
>
> Hello,
>
> On Mon, 13 Nov 2017, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > Could you please rebuild qtbase with OpenGL ES acceleration on ARM64
> > > instead so as to provide a better user experience on these devices?
> >
> > As discussed on IRC, it means beaking ABI and also arm64 is likely to
> > have DesktopOpenGL support as per
> > https://nullr0ute.com/2017/09/the-state-of-open-source-accelerated-graphic
> > s-on-arm-devices/
> >
> > So for the moment is a non-go.
>
> I asked on IRC and mitya57 told me that we can revisit this decision.
Sure thing. I even wrote to you on IRC on #debian-devel but you might have
missed it.

I want to stress a point here: in my reply below I might sound too negative,
but I have been struggling with this subject for at very least a couple of
years now. The big issue behind this is lack of proper data and industry
definitions in terms of what is the real trend behind all this.

That being said every data that can help us make a better decision will be
highly appreciated.

> I'm not an expert in this topic but in Kali we have quite some experience
> in providing Kali images for specific ARM devices. Right now we are
> working on getting Kali working in the Gemini PDA and this bug is a
> blocker:
> https://store.planetcom.co.uk/products/gemini-pda-1
>
> I asked a few questions to the person working on this project. My questions
>
> were those:
> > Can we reasonably say that most arm64 boards have OpenGL ES but no
> > regular OpenGL? Can you provide a somewhat up-to-date list to back up
> > this fact?
> > Can a QT compiled for OpenGL ES still benefit from some hardware
> > acceleration on a board with full OpenGL support?
>
> Here's the answer that I got from Re4son:
> > I haven't come across any arm64 chipset with an OpenGL enabled GPU apart
> > from 2 NVIDIA's CUDA based platforms. I've heard about the idea but they
> > were merely academic and nothing seems to have come out of it.  Quite
> > the opposite - everybody seem to toy with the idea of moving to Vulkan
> > rather than GL.
> > The core principle is to provide packages that match the GPU's attached
> > to the architecture and according to the following stats, all but 2 of
> > the GPU's attached to arm support only GLES:
> >
> > https://www.khronos.org/conformance/adopters/conformant-products/opengles
> > https://www.khronos.org/conformance/adopters/conformant-products/opengl
That's actually interesting data.
 
> > I haven't experimented with it, but according to the specifications
> > OpenGL GPU's are capable of running GLES applications albeit not to the
> > full potential of the hardware. The only scenario where I could see that
> > being an issue is when someone puts a GL enabled GPU in an arm64 server
> > and I cannot imagine that they are craving top shelf 3D acceleration of
> > their qt applications.

I would disagree with that, specially with the use of QML, but the arm64
server scenario is definitely not a fully deployed one yet so there is lot of
room for changes.

But I would *love* to have one more data point: how many of those boards
require the proprietary video card vendor's headers to be present at Qt build
time? Yes, some of them need to be present at qtbase's build time in order to
fully work (or even work at all).

Take a look at [experimental's] qtbase build. Look for "QPA backends" → "EGLFS
details". As you can see there is EGL support, but some vendors require
specific proprietary code to be present at build time. Even if it where not
proprietary they are self-excluding, ie, you can only pick one at a time.

[experimental's] <https://buildd.debian.org/status/fetch.php?pkg=qtbase-opensource-src&arch=amd64&ver=5.11.2%2Bdfsg-2&stamp=1537603343&raw=0>

So the question is: if we do the switch, how many boards we will really
support? And actually, did the switch to EGL really served the other arm*
archs? That really depends on the number of bards that do not require
proprietary stuff around at build time.

Side note: I have just created #909579 to see if we can add Vulkan support
without breaking anything else.

> > More objectively, Ubuntu did that switch two years ago and there have
> > been no issues reported in launchpad as a result of it.

This is not actually true. There's what I wrote above *and* the fact that this
breaks API/ABI. How so? Well, EGL is not compatible with GLU/GLUT, on which
many Qt-based applications rely upon, see [glut].

[glut] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798408#67>

Note that at the moment I was convinced to switch arm64 and we did know of few
packages that had issues. That changed.

So, let's suppose we get enough data to decide it's a good idea to switch
arm64. We would need a full blown transition to get this done, plus proper bug
reports to the affected packages in time plus either a soname bump or at very
very least changing the binary name libqt5core5a to libqt5core5b. Ideally we
would just do this, but changing SONAME should be the right thing to do. And
that means other distros will probably need to follow.

Can our current team deal with all that now that freeze is somewhat near and
autopkgtest have become, in terms of maintainer time, a problem more than a
solution? We are a very small team that not only supports 30+ library packages
but now also has to deal with other people's faulty autopkgtests to get a
transition done.

> He wanted to get some confirmation of all this but he did not manage to
> get any response from the experts he tried to contact.

That's, I'm afraid, the normal result when talking about video on ARM.

> Based on all this, it seems to me that we would better served by using
> OpenGL ES on arm64. If we don't do this, we should likely be providing
> conflicting packages to support both QT with OpenGL and QT with OpenGL ES
> but I can see that becoming rather hard to handle.

Right, and we are currently short of proper man power.

> And the fact that Ubuntu made the switch is reassuring: it can be done and
> it's likely the most useful choice right now. I'm ccing the Ubuntu
> developer who made the switch in case he can add something useful to this
> discussion (the change happened in qtbase-opensource-src
> (5.5.1+dfsg-17ubuntu2~2 in yakkety in 2016).

Timo was an active part of this team at that point too. He is also a DD.

Cheers, Lisandro.

--
You know you're brilliant, but maybe you'd like to understand what
you did 2 weeks from now.
  Linus Benedict Torvalds.

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: qtbase5-dev: Rebuild qtbase with OpenGL ES support for arm64

Re4son
Hi everyone,


On 26/09/18 01:05, Lisandro Damián Nicanor Pérez Meyer wrote:
Hi everybody!


Sure thing. I even wrote to you on IRC on #debian-devel but you might have 
missed it.

I want to stress a point here: in my reply below I might sound too negative, 
but I have been struggling with this subject for at very least a couple of 
years now. The big issue behind this is lack of proper data and industry 
definitions in terms of what is the real trend behind all this.
I really appreciate your hard work on this topic Lisandro and I'm very thankful for you agreeing to revisit this issue. I think there would be a huge benefit implementing this change.

That being said every data that can help us make a better decision will be 
highly appreciated. 
I have compiled some data for us to work with:
https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls

I'm currently working through this list to gauge the level of qt related activities with these boards (column g).
So far I can't see much activity at all but I'm still going through the forums of the more popular platforms. Could we start discussions with the ones documented?
I would disagree with that, specially with the use of QML, but the arm64 
server scenario is definitely not a fully deployed one yet so there is lot of 
room for changes.

But I would *love* to have one more data point: how many of those boards 
require the proprietary video card vendor's headers to be present at Qt build 
time? Yes, some of them need to be present at qtbase's build time in order to 
fully work (or even work at all).

Take a look at [experimental's] qtbase build. Look for "QPA backends" → "EGLFS 
details". As you can see there is EGL support, but some vendors require 
specific proprietary code to be present at build time. Even if it where not 
proprietary they are self-excluding, ie, you can only pick one at a time.

[experimental's] <https://buildd.debian.org/status/fetch.php?pkg=qtbase-opensource-src&arch=amd64&ver=5.11.2%2Bdfsg-2&stamp=1537603343&raw=0>

So the question is: if we do the switch, how many boards we will really 
support? And actually, did the switch to EGL really served the other arm* 
archs? That really depends on the number of bards that do not require 
proprietary stuff around at build time.
Good point. Let's take a conservative approach and assume all. That would still leave us with all arm64 boards being able to run KDE or LXQT.
People wanting to write their own window applications outside the actual windowing system would still need to build qt for their own needs as they had to in the past.
I haven't seen much evidence of people doing that. The few exceptions I have found are building their own qtbase with EGLF support for their platform.
Gauging the interest for a lightweight desktop environment on https://www.armbian.com/ and having experienced LXQT on the gemini, I am positive that this is going to be very well received and the combination of choice in the future.
Side note: I have just created #909579 to see if we can add Vulkan support 
without breaking anything else.

More objectively, Ubuntu did that switch two years ago and there have
been no issues reported in launchpad as a result of it.
This is not actually true. There's what I wrote above *and* the fact that this 
breaks API/ABI. How so? Well, EGL is not compatible with GLU/GLUT, on which 
many Qt-based applications rely upon, see [glut].

[glut] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798408#67>

Note that at the moment I was convinced to switch arm64 and we did know of few 
packages that had issues. That changed.

Also a good point, and a scary one, too.
I have done a scan of the activities in some of the board's forums and couldn't find any indication that anyone is, or has been, developing or running GLU applications on arm64.
I might be looking in the wrong corners of the Internet but it looks currently very quiet in the arm64 space when it comes to qt.
I would need a few more days to check out the forums and IRC channels of the popular boards to see what they are up to but we might have an opportunity to get this over the line before people start putting some serious effort into this space.


I understand that there is a considerable likelihood of something going wrong, you have plenty of experience from the Ubuntu switch, but the impact might be lower than last time.
I'm going out on a limb here, but:

- assuming that the uptake of qt on arm64 is currently very low
- GLU has been broken on armhf a few years ago already so people have probably been driven away from it
- ?? Doesn't FreeGLUT offer support for GLES ?? I have to dig into that a bit more

the impact on users may even be negligible compared to the benefit of having a proper desktop environment on all arm64 boards and, if the Gemini is a success, future arm64 handhelds.
Experiencing LXQT on those boards is leaps ahead of what is currently available and is something to be proud of.
Thanks heaps for your help with this, I much appreciate it.

Many thanks,
Re4son

Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Lisandro Damián Nicanor Pérez Meyer-2
In reply to this post by Rohan Garg-3
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>

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Paul Wise via nm
On Sun, Nov 25, 2018 at 8:58 PM Lisandro Damián Nicanor Pérez Meyer wrote:

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

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Raphael Hertzog-3
In reply to this post by Lisandro Damián Nicanor Pérez Meyer-2
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).

On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> It seems now clear that the general consensus seems to expect:
> = 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.

> 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,
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

signature.asc (535 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Jonas Smedegaard-2
Quoting Raphael Hertzog (2018-11-26 12:37:57)
> 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

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

riku voipio-7
In reply to this post by Raphael Hertzog-3
On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote:
> 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

Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Lisandro Damián Nicanor Pérez Meyer-2
In reply to this post by Raphael Hertzog-3
El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
> 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.

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


> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It seems now clear that the general consensus seems to expect:
> > = 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.

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Alan Corey
Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
compile your program?  Supply both libraries?  ES gives an enormous
performance boost to little machines that need it, desktop OpenGL is
more pretty pictures.

On 11/26/18, Lisandro Damián Nicanor Pérez Meyer <[hidden email]> wrote:

> El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
>> 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.
>
>> 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.
>
>
>> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
>> > It seems now clear that the general consensus seems to expect:
>> > = 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.
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>


--
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Lisandro Damián Nicanor Pérez Meyer-2
El lunes, 26 de noviembre de 2018 14:21:25 -03 Alan Corey escribió:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program?

It's a Qt build-time option. This in an upstream choice, not ours and not up
to us to fix.

> Supply both libraries?

Already answered in the thread.

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: Upcoming Qt switch to OpenGL ES on arm64

Re4son
In reply to this post by Rohan Garg-3
Hi,

On 2018-11-27 02:46 +0000, Wookey wrote:

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

> Not yet, no although I think you can just buy one (Gigabyte
> ThunderXstation) now. But Machiato-bin exists with working PCI and you
> can buy one
> (https://wiki.debian.org/InstallingDebianOn/Marvell/MACCHIATOBin), and
> nvidia-based hardware is available and supports GL (Jetson TX1)
> (https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1). There
> is more hardware coming which will support GL, so it is definately not
> as simple as 'available hardware is all GLES'. (Perhaps someone has
> made a list in this long thread).

I have previously compiled this excel sheet with data relevant to this thread:

https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls

Any feedback, correction and addition that could benefit this discussion would be appreciated.


> > > 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.
>
> OK. It seems that this project was started, but not completed due to a
> lack of interest at the time (2012) (people just started using GLES on
> dev boards/phones). It's here: https://code.launchpad.net/glproxy
> And here is the spec: https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Specs/1105/GLProxy

> Perhaps it is worth resurrecting this project if it would let us
> acheive the nirvana of runtime selection between GL and GLES, thus
> making everyone happy.

> Jammy Zhou [hidden email] cc:ed can say how much was/wasn't done.

That is extremely interesting, anything I can do to help?

> Wookey

Many thanks,
Re4son
Reply | Threaded
Open this post in threaded view
|

Bug#881333: tracking OpenGL support for specific boards

Jonas Smedegaard-2
Quoting Re4son (2018-11-27 11:38:14)

> On 2018-11-27 02:46 +0000, Wookey wrote:
> > >
> > > 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?
>
> > Not yet, no although I think you can just buy one (Gigabyte
> > ThunderXstation) now. But Machiato-bin exists with working PCI and
> > you can buy one
> > (https://wiki.debian.org/InstallingDebianOn/Marvell/MACCHIATOBin),
> > and nvidia-based hardware is available and supports GL (Jetson TX1)
> > (https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1).
> > There is more hardware coming which will support GL, so it is
> > definately not as simple as 'available hardware is all GLES'.
> > (Perhaps someone has made a list in this long thread).
>
> I have previously compiled this excel sheet with data relevant to this thread:
>
> https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls
>
> Any feedback, correction and addition that could benefit this discussion would be appreciated.
Great that you collected that dataset, and put it public.

What would help further would be for such information having references
to sources, and each information point be referencable (not only the
dataset as a whole).

In other words, your data gets 2 stars: https://5stardata.info/en/

I maintain https://wiki.debian.org/CheapServerBoxHardware and have for a
long time wanted to make that 5-star data (currently that has 3 stars).
Would be great to include your dataset in that, but I would then need to
know the sources for the datapoints to be able to verify.  Also, ideal
would be that you maintain your dataset yourself as 5-star reusable data
instead of me needing to maintain a fork.

A user-visible benefit of 5-star data is the possibility for not only
browsing it as tabular data, but also navigating multiple dimensions
e.g. like https://kumu.io/DigLife/digital-life-collective#our-network

Please tell me if interested in helping out, and I will provide concrete
examples of how to optimally organize data, as soon as I get it
documented for my own work.


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: tracking OpenGL support for specific boards

Bret Curtis
> > https://github.com/Re4son/kali-gemini-multistrap-config/raw/files/Arm64List.xls
> >
> > Any feedback, correction and addition that could benefit this discussion would be appreciated.
>
> Great that you collected that dataset, and put it public.
>
> What would help further would be for such information having references
> to sources, and each information point be referencable (not only the
> dataset as a whole).
>

Isn't this already done for us here?
https://gpuinfo.org/

If anything, it should be used to fill in that list.
Many of those chipsets you list, as I understand, have a mesa driver
for them that support opengl and gles.
Such as freedreno which supports Mali A4XX series. https://mesamatrix.net/

Keep in mind, only the proprietary drivers seem to not support opengl
while the hardware is perfectly capable of doing so.

Cheers,
Bret

Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Rohan Garg-3
In reply to this post by Raphael Hertzog-3
Hey

On Mon, Nov 26, 2018 at 12:38 PM Raphael Hertzog <[hidden email]> wrote:
>
> 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).
>

Having worked on multiple ARM boards over the past 3 years,
I agree very strongly with Raphael.

> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It seems now clear that the general consensus seems to expect:
> > = 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.
>

As the person who opened #881333, I completely agree. I've been on vacation
the past 10 days and haven't had a opportunity to chime in.

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

I've had multiple concrete projects involving KDE, Qt and ARM over the past
few years, over multiple ARM platforms such as the ODROID C1, C2 and the
Pinebook. With my KDE hat on, we have a strong stake in having Plasma
perform decently well on these devices.

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

I concur here. It was correctly pointed out in another reply that by using
OpenGL we're specifically catering to software that doesn't support
GLES while making performance worse for mature applications that
do implement both OpenGL and GLES. The reality of the situation is that
the market currently favors GLES over GL on ARM SBC's, delivered with
proprietary blobs. I think a more pragmatic view of this reality would be to
deliver the best FOSS user experience that's possible with the proprietary
drivers while the open source drivers are being improved. To that extent,
by switching to GLES we improve the overall situation since OpenGL
applications can fall back to software rendering via mesa on platforms
where mesa does not support the GPU.

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

By choosing to build Qt with GLES on ARM64, we make Debian a more
attractive platform for vendors who'd like to target ARM64 boards.

Cheers
Rohan Garg

Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Dmitry Shachnev-3
Hi Rohan!

On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote:

> [...]
>
> I concur here. It was correctly pointed out in another reply that by using
> OpenGL we're specifically catering to software that doesn't support
> GLES while making performance worse for mature applications that
> do implement both OpenGL and GLES. The reality of the situation is that
> the market currently favors GLES over GL on ARM SBC's, delivered with
> proprietary blobs. I think a more pragmatic view of this reality would be to
> deliver the best FOSS user experience that's possible with the proprietary
> drivers while the open source drivers are being improved. To that extent,
> by switching to GLES we improve the overall situation since OpenGL
> applications can fall back to software rendering via mesa on platforms
> where mesa does not support the GPU.
Here I agree with Luke Kenneth Casson Leighton’s opinion [1].

I think we should aim to provide the best possible experience with the free
software ecosystem. The experience with proprietary drivers should be the
second priority, if priority at all.

> By choosing to build Qt with GLES on ARM64, we make Debian a more
> attractive platform for vendors who'd like to target ARM64 boards.

We should make it attractive for vendors to release their code under
a free software (DFSG) license. That way anyone would be able to hack on it
and add missing support for a different OpenGL variant, if needed.

That said, as Lisandro announced, we will be happy to make any decision
if there is either a consensus or a TC decision about it.

[1]: https://lists.debian.org/debian-devel/2018/11/msg00622.html

--
Dmitry Shachnev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Lisandro Damián Nicanor Pérez Meyer-2
El martes, 27 de noviembre de 2018 17:19:32 -03 Dmitry Shachnev escribió:

> Hi Rohan!
>
> On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote:
> > [...]
> >
> > I concur here. It was correctly pointed out in another reply that by using
> > OpenGL we're specifically catering to software that doesn't support
> > GLES while making performance worse for mature applications that
> > do implement both OpenGL and GLES. The reality of the situation is that
> > the market currently favors GLES over GL on ARM SBC's, delivered with
> > proprietary blobs. I think a more pragmatic view of this reality would be
> > to deliver the best FOSS user experience that's possible with the
> > proprietary drivers while the open source drivers are being improved. To
> > that extent, by switching to GLES we improve the overall situation since
> > OpenGL applications can fall back to software rendering via mesa on
> > platforms where mesa does not support the GPU.
>
> Here I agree with Luke Kenneth Casson Leighton’s opinion [1].
>
> I think we should aim to provide the best possible experience with the free
> software ecosystem. The experience with proprietary drivers should be the
> second priority, if priority at all.
I can't but agree here.

--
Una vez que hemos eliminado lo imposible, lo que queda, por improbable que
parezca, es la verdad.
  Sherlock Holmes

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

Rohan Garg-3
In reply to this post by Dmitry Shachnev-3
Hey
> Here I agree with Luke Kenneth Casson Leighton’s opinion [1].
>
> I think we should aim to provide the best possible experience with the free
> software ecosystem. The experience with proprietary drivers should be the
> second priority, if priority at all.
>

AFAIU by building Qt with GLES we'd still be able to make use of mesa as it
provides both GL and GLES capabilities, while also allowing Qt to make use
of blobs if a user so chooses.

> > By choosing to build Qt with GLES on ARM64, we make Debian a more
> > attractive platform for vendors who'd like to target ARM64 boards.
>
> We should make it attractive for vendors to release their code under
> a free software (DFSG) license. That way anyone would be able to hack on it
> and add missing support for a different OpenGL variant, if needed.
>
> That said, as Lisandro announced, we will be happy to make any decision
> if there is either a consensus or a TC decision about it.
>

Ack.

Cheers
Rohan Garg

12