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

[Lisandro Damián Nicanor Pérez Meyer]

Hi everybody!

El martes, 25 de septiembre de 2018 11:07:31 -03 Raphael Hertzog escribió:
> Control: reopen -1 hert...@debian.org
> 
> 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] 


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] 

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 

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

[Debian Bug Tracking System]

Processing control commands:

> reopen -1 hert...@debian.org
Bug #881333 {Done: Lisandro Damián Nicanor Pérez Meyer } 
[qtbase5-dev] qtbase5-dev: Rebuild qtbase with OpenGL ES support for arm64
Bug reopened
Changed Bug submitter to 'hert...@debian.org' from 'Rohan Garg '.
Ignoring request to alter fixed versions of bug #881333 to the same values 
previously set

-- 
881333: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881333
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Raphael Hertzog]

Control: reopen -1 hert...@debian.org

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
Description: PGP signature

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

[Lisandro Damián Nicanor Pérez Meyer]

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
Description: This is a digitally signed message part.

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

[Rohan Garg]

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  libqt5dbus55.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  libqt5printsupport55.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5sql5 5.9.1+dfsg-2+16.04+xenial+build25
ii  libqt5test55.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-dev2: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  

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

-- no debconf information