subject:"Upcoming Qt switch to OpenGL ES on arm64"

On Tue, Nov 27, 2018 at 10:13:06PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez 
> Meyer escribió:
> [snip]
> > > > prepare dual stack packages that use the symbols file magic from
> > > > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > > > packages which are libraries and which end up with a dependency only on
> > > > the
> > > > GL version of the package instead of a dependency on GL | GLES.

> > On a second thought: suppose a library libexample that uses the symbols as
> > provided by the current libqt5gui5 (either with one or the other version)
> > but does not exposes it's symbols. The end result will not make
> > libexample's symbols change but will for sure it's internal usage of
> > libqt5gui5. How can one differentiate libraries like libexample from other
> > libraries that do use libqt5gui5 but not it's OpenGL stuff?

> Or maybe even applications! Let's suppose libqt5qml5 follows the libexample 
> example (it *does* requires some kind of OpenGL). Now qtcreator (to name just 
> one application) does usage of it, and users will surely want to use the 
> right 
> build for their use case. Building two qtcreator binaries sounds like just 
> too 
> much.

> Now get Plasma. It does a heavy usage of QML. In *lots* of places and 
> packages.

> At this point I really feel that, except I am missing something, double 
> building is just not a good idea :-/

Ok, I don't think you've understood then.  Perhaps a further example from
the Ubuntu archive would help.  As of Ubuntu 16.04, here is the *complete*
list of packages that had a hard dependency on any of the 5 GL-linked Qt
libraries, where that dependency could not instead be satisfied by the GLES
build:

$ grep-dctrl -n -sSource:Package -FDepends \
-e 
'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
 5\.[0-9.]*\))(?|$),' \

/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_*binary-amd64_Packages
 | sort -u
maliit-plugins
ovito
pyqt5
qml-box2d
qt3d-opensource-src
qtbase-opensource-src
qtdeclarative-opensource-src
qtubuntu-cameraplugin-fake
stellarium
wallch
$

Every single other binary package that depends on libqt5gui5 (etc) in Ubuntu
16.04 has an ORed dependency on libqt5gui5 | libqt5gui5-gles.

Three of the results in this list are familiar; they were already in the set
of dual-stack libraries.

Several are applications (ovito, stellarium, wallch), and if they say they
require full GL, that's legitimate, and that just means users would only be
able to install them on systems using the full desktop GL.  (That's fine,
and certainly better than not being able to build/install them at all.)

maliit-plugins is not an application, but it's a rather specialized
component with no reverse-dependencies (i.e. not a library).

qml-box2d is likely to have never been uploaded after the symbols handling
was implemented in Ubuntu, therefore never picked up the alternate
dependencies (the package isn't in Debian, anyway).

And pyqt5, since it's language bindings for the full Qt API, would also need
to be double-built (but had not been in Ubuntu).

The qml packages built from these libraries - qml-module-qtlocation,
qml-module-qtmultimedia, qtdeclarative5-qtlocation-plugin - would also need
proper handling, but the impact on dependency graphs should be similarly
self-limiting; because just as for C programs, the vast majority of QML
applications don't care about the distinction between GL and GLES backends
and *expect* Qt to abstract this away for them.

So based on this, Ubuntu missed exactly one package in order to fully
support both GL and GLES builds of Qt, bringing the total to 6 instead of 5.

There might be more now, but I'd be surprised if the total number of
affected source packages in Debian today reached double digits; and in any
case the question lends itself to the same sort of analysis as above, so
anyone interested in doing this in Debian can reasonably work out the scope.

And each of those gles source packages is a purely mechanical transformation
of the base Qt source package.

So perhaps someone in this thread is willing to put in this effort to
maintain 6 source packages, in order to avoid having to make a choice
between GL and GLES on arm64.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

signature.asc
Description: PGP signature

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

2018-11-27 Thread Paul Wise

On Wed, Nov 28, 2018 at 7:30 AM Lisandro Damián Nicanor Pérez Meyer wrote:

> Just curious: is there any project alive for the PowerVR SGX530 ?

There used to be a very brief effort around PowerVR devices but it
looks like that has died now. Some of the project site was captured by
archive.org and lkcl's part of the work is still on his site. If
anyone wants to start a new reverse engineering effort, I strongly
suggest to start it on a hosting service close to the existing
Xorg/etc communities that will last long-term (like
freedesktop.org/x.org) instead of one that might disappear at any
moment.

https://wiki.debian.org/Mobile#software-drivers
https://web.archive.org/web/20170620135604/http://powervr.gnu.org.ve:80/doku.php
https://libreplanet.org/wiki/Group:PowerVR_drivers
http://lkcl.net/powervr/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-27 Thread Lisandro Damián Nicanor Pérez Meyer

El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
[snip]
> > > prepare dual stack packages that use the symbols file magic from
> > > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > > packages which are libraries and which end up with a dependency only on
> > > the
> > > GL version of the package instead of a dependency on GL | GLES.
> 
> On a second thought: suppose a library libexample that uses the symbols as
> provided by the current libqt5gui5 (either with one or the other version)
> but does not exposes it's symbols. The end result will not make
> libexample's symbols change but will for sure it's internal usage of
> libqt5gui5. How can one differentiate libraries like libexample from other
> libraries that do use libqt5gui5 but not it's OpenGL stuff?

Or maybe even applications! Let's suppose libqt5qml5 follows the libexample 
example (it *does* requires some kind of OpenGL). Now qtcreator (to name just 
one application) does usage of it, and users will surely want to use the right 
build for their use case. Building two qtcreator binaries sounds like just too 
much.

Now get Plasma. It does a heavy usage of QML. In *lots* of places and 
packages.

At this point I really feel that, except I am missing something, double 
building is just not a good idea :-/


-- 
firmaware: soft cuya licencia pagas enviando un autografo
  StucKman en #grulic, irc.freenode.net

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


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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-27 Thread Lisandro Damián Nicanor Pérez Meyer

El martes, 27 de noviembre de 2018 21:19:20 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez
> 
> Meyer wrote:
> [snip]
> 
> > > Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt
> > > maintainer).  He points me out that those 7 packages were needed for the
> > > Ubuntu Touch port which, I presume, does not counts KDE's Plasma or KF
> > > libraries.  The question is then: how would this affect other stacks
> > > like
> > > the ones I mentioned before?  And then there might be other libraries
> > > involved.  Granted, we do not know exactly which ones but...
> > 
> > It is actually fairly easy to answer this question as well: simply
> > identify
> > all the packages in the archive that depend on one of the known dual-stack
> > libraries,
> 
> That's libqt5gui5:
> 
> 
> 
> And that's just the tip of the iceberg. libqt5gui5 is surely the second most
> used library provided by Qt just before libqt5core5.
> 
> > prepare dual stack packages that use the symbols file magic from
> > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > packages which are libraries and which end up with a dependency only on
> > the
> > GL version of the package instead of a dependency on GL | GLES.

On a second thought: suppose a library libexample that uses the symbols as 
provided by the current libqt5gui5 (either with one or the other version) but 
does not exposes it's symbols. The end result will not make libexample's 
symbols change but will for sure it's internal usage of libqt5gui5. How can 
one differentiate libraries like libexample from other libraries that do use 
libqt5gui5 but not it's OpenGL stuff?

Maybe there is a way, but I sincerely do not know (other tan trial and error, 
of course).

-- 
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem
and you will not get to space today.
  http://xkcd.com/1133/

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


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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-27 Thread Lisandro Damián Nicanor Pérez Meyer

El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
[snip] 
> > Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt
> > maintainer).  He points me out that those 7 packages were needed for the
> > Ubuntu Touch port which, I presume, does not counts KDE's Plasma or KF
> > libraries.  The question is then: how would this affect other stacks like
> > the ones I mentioned before?  And then there might be other libraries
> > involved.  Granted, we do not know exactly which ones but...
> 
> It is actually fairly easy to answer this question as well: simply identify
> all the packages in the archive that depend on one of the known dual-stack
> libraries, 

That's libqt5gui5:



And that's just the tip of the iceberg. libqt5gui5 is surely the second most 
used library provided by Qt just before libqt5core5.

> prepare dual stack packages that use the symbols file magic from
> Ubuntu, rebuild all the reverse-dependencies, and identify all those
> packages which are libraries and which end up with a dependency only on the
> GL version of the package instead of a dependency on GL | GLES.
> 
> A fair amount of compile time required to do this analysis, but relatively
> little human time.

As long as the human behind it has a way to simply trigger this rebuilds 
automatically. I think Ubuntu has by using launchpad. We in Debian don't 
(please prove me wrong!). On my current machine that would take 
approximately... a couple of months. Without using it for anything else.

Of course, if anyone feels like doing it... :-)

-- 
http://mx.grulic.org.ar/lurker/message/20081108.174208.4f42e55c.es.html
Así se corrobora el software legal en Argentina

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


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

Re: Upcoming Qt switch to OpenGL ES on arm64

On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg->
> >  2ubuntu4~1

> > And here is the list of all packages that required dual-stack at least as of
> > 2017, when Ubuntu stopped development on this:

> > $ wget -O - -q
> > http://old-releases.ubuntu.com/ubuntu/dists/zesty/universe/source/Sources.g
> > z \ zcat | grep-dctrl -FPackage -r qt.*gles -sPackage
> > Package: qt3d-opensource-src-gles
> > Package: qtbase-opensource-src-gles
> > Package: qtdeclarative-opensource-src-gles
> > Package: qtlocation-opensource-src-gles
> > Package: qtmir-gles
> > Package: qtmultimedia-opensource-src-gles
> > Package: qtubuntu-gles
> > $

> > i.e. 7 source packages total, and 2 of them Ubuntu-Touch-specific (qtmir,
> > qtubuntu).

> And to be honest two of those packages where exclusive to ubuntu: qtmir-gles 
> and qtubuntu-gles.

> > Maybe you were already aware of this, but it didn't come across to me in
> > your mail, sorry. 

> Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt
> maintainer).  He points me out that those 7 packages were needed for the
> Ubuntu Touch port which, I presume, does not counts KDE's Plasma or KF
> libraries.  The question is then: how would this affect other stacks like
> the ones I mentioned before?  And then there might be other libraries
> involved.  Granted, we do not know exactly which ones but...

It is actually fairly easy to answer this question as well: simply identify
all the packages in the archive that depend on one of the known dual-stack
libraries, prepare dual stack packages that use the symbols file magic from
Ubuntu, rebuild all the reverse-dependencies, and identify all those
packages which are libraries and which end up with a dependency only on the
GL version of the package instead of a dependency on GL | GLES.

A fair amount of compile time required to do this analysis, but relatively
little human time.

If someone was interested in volunteering to ensure both GL and GLES were
supported by Qt, this is where I would suggest they start, in order to
accurately size the effort involved and know what they're signing up for.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

signature.asc
Description: PGP signature

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

2018-11-27 Thread Lisandro Damián Nicanor Pérez Meyer

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

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

2018-11-27 Thread Lisandro Damián Nicanor Pérez Meyer

El domingo, 25 de noviembre de 2018 21:18:39 -03 Paul Wise escribió:
> 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.

Just curious: is there any project alive for the PowerVR SGX530 ?

Yes, they are mostly found on armhf devices, but as far as I know there is 
only the proprietary (and crappy) driver.

-- 
La vida no se mide por la cantidad de veces que respiramos,
sino por la cantidad de momentos que nos quitan la respiración.
  Anónimo

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


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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-27 Thread Lisandro Damián Nicanor Pérez Meyer

Hi Steve!

First of all: thanks for chiming in!

El martes, 27 de noviembre de 2018 19:06:27 -03 Steve Langasek escribió:
> Hi Lisandro,
[snip]
> > 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.
> 
> Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
> 
> Yes, GL vs. GLES impacts the ABI of libqt5gui5; HOWEVER, the set of
> reverse-dependencies that are actually impacted by the GL-specific ABI
> difference is actually quite small; and by using clever symbols files, the
> impact on the dependency tree can be minimized.
> 
> If anyone wants to dig into this further, perhaps for proof-of-concept, here
> is packaging that could be used as a starting point for the symbols files:
> 
>  
> https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg-> 
> 2ubuntu4~1
> 
> And here is the list of all packages that required dual-stack at least as of
> 2017, when Ubuntu stopped development on this:
> 
> $ wget -O - -q
> http://old-releases.ubuntu.com/ubuntu/dists/zesty/universe/source/Sources.g
> z \ zcat | grep-dctrl -FPackage -r qt.*gles -sPackage
> Package: qt3d-opensource-src-gles
> Package: qtbase-opensource-src-gles
> Package: qtdeclarative-opensource-src-gles
> Package: qtlocation-opensource-src-gles
> Package: qtmir-gles
> Package: qtmultimedia-opensource-src-gles
> Package: qtubuntu-gles
> $
> 
> i.e. 7 source packages total, and 2 of them Ubuntu-Touch-specific (qtmir,
> qtubuntu).

And to be honest two of those packages where exclusive to ubuntu: qtmir-gles 
and qtubuntu-gles.

> Maybe you were already aware of this, but it didn't come across to me in
> your mail, sorry. 

Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt 
maintainer). He points me out that those 7 packages were needed for the Ubuntu 
Touch port which, I presume, does not counts KDE's Plasma or KF libraries. The 
question is then: how would this affect other stacks like the ones I mentioned 
before? And then there might be other libraries involved. Granted, we do not 
know exactly which ones but...

> If you still think it is too much maintenance overhead to
> provide a dual stack for these 5 libraries (plus any others that later
> start to use GL-dependant ABIs), I think you're absolutely entitled to that
> view.

..yes, we are a team of roughly 3 people, mostly not available the three at 
the same time. It is not a strange situation that *just* one of us prepares 
almost (if not all) the full stack when a new release happens and sometimes 
even one of the others gets to handle the transition needed for private 
symbols (and thus getting it into unstable properly).

We are indeed having help from new contributors in some points, and I really 
hope they step up even more in the future, but currently the stack is huge for 
us. Heck, we don't even manage to handle tests for some submodules, let's not 
even think on autopkgtests.

But then let's suppose new manpower arrives, maybe dedicated to the task. The 
question is then: how many other packages this will affect? Will all the other 
maintainers be able to handle double stacks if needed? Is it really good to 
"kind of" impose even more work to maintainers? The KDE-related stack is 
possibly even bigger than Qt, and to the best of my knowledge there are just a 
handful of people maintaining it.

My current answer is: I really don't know.

-- 
Q. How did the programmer die in the shower?
A. He read the shampoo bottle instructions: Lather. Rinse. Repeat.
  http://www.devtopics.com/best-programming-jokes/

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


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

Re: Upcoming Qt switch to OpenGL ES on arm64

Hi Lisandro,

On Fri, Nov 23, 2018 at 11:05:11PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Andy: explicitly CCing you because I think it answers part of a question you 
> did but in another part of the thread.

> El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
> > On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
> [snip]
> > >Can you build two packages and allow user to select, which one he wants to
> > >install? Or those packages will be binary incompatible?

> > That's a good question, yes. It'w ahst I was wondering too.

> And that's a perfectly valid question, one we did in 2015, Ubuntu tried out 
> (as Dmitry pointed out) and did not work.

> Why?

> Short story: really *too* complicated and error prone.

> Long story:

> Please first check this image:

> 

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

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

Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.

Yes, GL vs. GLES impacts the ABI of libqt5gui5; HOWEVER, the set of
reverse-dependencies that are actually impacted by the GL-specific ABI
difference is actually quite small; and by using clever symbols files, the
impact on the dependency tree can be minimized.

If anyone wants to dig into this further, perhaps for proof-of-concept, here
is packaging that could be used as a starting point for the symbols files:

  
https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg-2ubuntu4~1

And here is the list of all packages that required dual-stack at least as of
2017, when Ubuntu stopped development on this:

$ wget -O - -q 
http://old-releases.ubuntu.com/ubuntu/dists/zesty/universe/source/Sources.gz \
zcat | grep-dctrl -FPackage -r qt.*gles -sPackage
Package: qt3d-opensource-src-gles
Package: qtbase-opensource-src-gles
Package: qtdeclarative-opensource-src-gles
Package: qtlocation-opensource-src-gles
Package: qtmir-gles
Package: qtmultimedia-opensource-src-gles
Package: qtubuntu-gles
$

i.e. 7 source packages total, and 2 of them Ubuntu-Touch-specific (qtmir,
qtubuntu).

Maybe you were already aware of this, but it didn't come across to me in
your mail, sorry.  If you still think it is too much maintenance overhead to
provide a dual stack for these 5 libraries (plus any others that later start
to use GL-dependant ABIs), I think you're absolutely entitled to that view.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

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

2018-11-27 Thread Dmitry Shachnev

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

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

On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
> Steve Langasek  writes:

> > Long ago I heard rumors of development work on mesa that would allow it to
> > function as a proxy library, so that apps would link against libGL as needed
> > and the GL implementation would use a hardware-accelerated GLES driver where
> > possible, falling back to software GL where necessary.

> This seems unlikely -- I believe GLES and GL have different semantics in
> a few places which makes implementing GL on GLES inefficient; mostly
> that GLES is missing stuff that GL applications often use, but I think
> there are places where GLES is just different, including in how GLSL
> works.

Perhaps that explains why no one ever actually succeeded in implementing it,
then?

Thanks for the context.

> I haven't tried, but I would expect that applications could use both GL
> and GLES APIs at the same time, even to the same window. If this does
> work with Mesa, then linking Qt against GLES wouldn't restrict
> applications using free drivers at least?

My recollection is that this becomes a practical problem of applications
that want to use both Qt and GL being unbuildable due to namespace
collisions at build time.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

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

2018-11-27 Thread Rohan Garg

Hey

On Mon, Nov 26, 2018 at 12:38 PM Raphael Hertzog  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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-27 Thread Re4son

Hi,

On 2018-11-27 02:46 +, 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  cc:ed can say how much was/wasn't done.

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

> Wookey

Many thanks,
Re4son

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

2018-11-27 Thread Re4son

Hi,

On 26/11/18 11:54 pm, Riku Voipio wrote:
> 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.

I fully agree again.
Looking at the lengthy progress so far and the limited resources
available, I suggest supporting the development by switching to GLES and
work on the drivers to support that first. Once that has been achieved
we can aim for full OpenGL support and then we can switch back to
desktop if there is actual user demand. I'm not suggesting to make
Debian more friendly to proprietary drivers. The exact opposite:
switching to GLES to fill the void will give us time to aim for one
milestone at a time. The vast majority of devices we are talking about
are embedded systems, let's aim to bring them the drivers and interfaces
that have been designed for embedded systems before we reach for the stars.
A lot of the discussion in this thread seems off topic and academic but
I’m confident that the above approach is what we need to move on.

> Riku
>
Many thanks

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-27 Thread Re4son

Hi,

On 26/11/18 8:58 pm, Riku Voipio wrote:
> On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
>> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
>
>> 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.
>
I agree, hence let's do the switch and focus on developing free drivers.
I fully echo your sentiment and propose a practical approach to give the
best possible support to the developers whilst also providing something
real to the user. In awe of the efforts that have already gone into
these development activities - right now we don't have the drivers, thus
we lack both OpenGL & OpenGL ES support for the majority of the arm64
platforms and considering the hard work and time it has taken already, I
doubt that we will have stable full OpenGL support anytime soon.
Making the switch means that we can give the hardware the proprietary
support available right now, develop GLES support, roll it out, extend
it to full OpenGL support and once that is reasonably mature switch back
to desktop.

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread Luke Kenneth Casson Leighton

On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer
wrote:

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

here's a perspective that may not have been considered: how much
influence and effect on purchasing decisions would the choice made
have?

we know that proprietary embedded GPUs and associated proprietary
software are not just unethical, and cause huge problems, they also
hurt company profits and cause increases in support costs.

by complete contrast, when all the source code is libre-licensed, this
is what happens:

http://www.h-online.com/open/news/item/Intel-and-Valve-collaborate-to-develop-open-source-graphics-drivers-1649632.html

basically what i am inviting you to consider is that in making this
decision, the one that supports, encourages and indirectly endorses
the continued propagation of proprietary 3D libraries is one that is
going to have a massive world-wide adverse financial impact over time.

i would therefore strongly recommend prioritising decisions that
support libre-licensed GPU firmware and PCIe GPU cards that have
libre-licensed source code.

if systems with etnaviv are "punished" for example by this decision,
that would not go down too well. if people running older Radeon GPU
Cards (on the RockPro64 which has a 4x PCIe Card that easily runs at
2500 MBytes/sec) find that their cards perform badly, that is also not
going to go down well.

bottom line: your decisions here have far more impact than you may realise.

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread Wookey

On 2018-11-23 23:10 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> > 
> > 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?

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 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  cc:ed can say how much was/wasn't done.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

signature.asc
Description: PGP signature

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

2018-11-26 Thread Keith Packard

Steve Langasek  writes:

> Long ago I heard rumors of development work on mesa that would allow it to
> function as a proxy library, so that apps would link against libGL as needed
> and the GL implementation would use a hardware-accelerated GLES driver where
> possible, falling back to software GL where necessary.

This seems unlikely -- I believe GLES and GL have different semantics in
a few places which makes implementing GL on GLES inefficient; mostly
that GLES is missing stuff that GL applications often use, but I think
there are places where GLES is just different, including in how GLSL
works.

I haven't tried, but I would expect that applications could use both GL
and GLES APIs at the same time, even to the same window. If this does
work with Mesa, then linking Qt against GLES wouldn't restrict
applications using free drivers at least?

-- 
-keith

signature.asc
Description: PGP signature

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

2018-11-26 Thread Steve Langasek

On Mon, Nov 26, 2018 at 12:21:25PM -0500, Alan Corey wrote:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program?  Supply both libraries?

Because this requires providing two separate *stacks* of source packages,
one for GL and one for GLES, which from Ubuntu's experience doing this
previously for Ubuntu Touch, I can say is a non-trivial amount of
maintenance overhead.

There is some prior art here that I could provide pointers to if the Debian
Qt maintainers did decide to take this on, but best case is that you still
have two sets of about a half dozen source packages that have to be kept in
sync.

> ES gives an enormous performance boost to little machines that need it,
> desktop OpenGL is more pretty pictures.

Long ago I heard rumors of development work on mesa that would allow it to
function as a proxy library, so that apps would link against libGL as needed
and the GL implementation would use a hardware-accelerated GLES driver where
possible, falling back to software GL where necessary.

Since we are still having this conversation about having to choose between
GL and GLES at compile time, I infer that this has not come to fruition.

> On 11/26/18, Lisandro Damián Nicanor Pérez Meyer  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
> 

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread Ben Hutchings

On Sat, 2018-11-24 at 21:51 +0100, Adam Borowski wrote:
> On Sat, Nov 24, 2018 at 06:06:16PM +, Ben Hutchings wrote:
> > On Sat, 2018-11-24 at 15:21 +, Simon McVittie wrote:
> > [...]
> > > Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
> > > user-space driver, which is an open source stack if you don't count the
> > > GPU firmware. It should be comparable to the situation on Intel integrated
> > > GPUs (but a lot faster and more featureful, and probably with more bugs,
> > > because the hardware is faster and more featureful). Expect to need a
> > > recent (buster/sid) kernel, particularly for newer hardware.
> > 
> > I installed an AMD RX550 based card last year.  It required updates to
> > the kernel, firmware, X driver, and Mesa, which are all available in
> > stretch-backports.
> 
> Oooh, sounds like you have at least some clue here -- _and_ there are
> non-trivial things one should know.  As you can tell from my vitriol,
> there's no way I'm going to use anything from nVidia -- yet I need to
> replace most of my main home box quite badly.
> 
> Thus, are there any particular setups you'd recommend for someone running
> unstable and Linus' current kernels?
[...]

That machine usually runs stretch + backports, so I don't have anything
to say about unstable.

Ben.

-- 
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.




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

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

2018-11-26 Thread 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  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

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

2018-11-26 Thread Lisandro Damián Nicanor Pérez Meyer

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread 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.

On 11/26/18, bret curtis  wrote:
> Hello Ian,
>
> On Mon, Nov 26, 2018 at 2:04 PM Ian Campbell  wrote:
>>
>> On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
>> > 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/
>
>


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

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

2018-11-26 Thread Lisandro Damián Nicanor Pérez Meyer

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread bret curtis

Hello Ian,

On Mon, Nov 26, 2018 at 2:04 PM Ian Campbell  wrote:
>
> On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> > 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/

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

2018-11-26 Thread Riku Voipio

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread Ian Campbell

On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> 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.

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

2018-11-26 Thread Jonas Smedegaard

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

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread bret curtis

Hi!

On Mon, Nov 26, 2018 at 11:40 AM Raphael Hertzog  wrote:
> >
> > 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.

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

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

Hello,

On Sat, 24 Nov 2018, bret curtis wrote:
> 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.

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread bret curtis

> On Sat, 24 Nov 2018, bret curtis wrote:
> > 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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread Riku Voipio

On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
> > 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

Re: Upcoming Qt switch to OpenGL ES on arm64

Hi,

On Fri, 23 Nov 2018, Dmitry Shachnev wrote:
> According to config_help.txt [1], Qt uses ES2 by default on Windows.

Interesting.

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

Re: Upcoming Qt switch to OpenGL ES on arm64

Hello Bret,

On Sat, 24 Nov 2018, bret curtis wrote:
> 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,
-- 
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/

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

2018-11-25 Thread Paul Wise

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-25 Thread Adam Borowski

On Sun, Nov 25, 2018 at 06:28:45AM +0100, Tollef Fog Heen wrote:
> ]] Adam Borowski 
> 
> > Tested on an early bronze age i386 box with an "82915G/GV/910GL"; both
> > glxgears and es2gears_x11 work fine.  I don't think anyone is going to run a
> > modern desktop environment on a machine older than that.
> > 
> > But that's an Intel card -- with nVidia, stuff 3 years old gets dropped from
> > the official drivers while 2 years old doesn't get Linux support yet -- and
> > nouveau has problems on its own.
> 
> es2gears_x11 works fine on my GF116 board (release date: 2011-03-15)
> using the proprietary drivers (on an otherwise testing system).

That's because our Debian maintainers are not hasty at packaging new drivers
with such "improvements".  The support for your card's generation and the
next (400 and 500) is long since dropped in nVidia's mainline.

A glance at upstream's site discouraged me from searching for information
when _they_ dropped it, but in Debian, the droppage reached experimental in
April 2018.

So -- my figure of 3 years was exaggerated, but so is your defense.

I guess the Debian packages will once again fork the old drivers, but at
least upstream security support for them ends Jan 2019, which for something
that requires a kernel driver is deeply troubling.

And, it means no porting to new kernels -- nearly at all, as opposed to
supported cards being "only" 0-3 months behind a stable release.  So sorry,
that's simply not an option for a good part of us.  As for nouveau, you
don't know if it actually works adequately for your card until you buy it.

Thus, Linus' message was neither strong nor expressive enough.

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

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

2018-11-25 Thread 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

  

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


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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Tollef Fog Heen

]] Adam Borowski 

> Tested on an early bronze age i386 box with an "82915G/GV/910GL"; both
> glxgears and es2gears_x11 work fine.  I don't think anyone is going to run a
> modern desktop environment on a machine older than that.
> 
> But that's an Intel card -- with nVidia, stuff 3 years old gets dropped from
> the official drivers while 2 years old doesn't get Linux support yet -- and
> nouveau has problems on its own.

es2gears_x11 works fine on my GF116 board (release date: 2011-03-15)
using the proprietary drivers (on an otherwise testing system).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Upcoming Qt switch to OpenGL ES on arm64

Hey Scott,

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

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

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

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

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

Cheers,
Bret

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Adam Borowski

On Sat, Nov 24, 2018 at 09:51:49PM +0100, Adam Borowski wrote:
> On Sat, Nov 24, 2018 at 06:06:16PM +, Ben Hutchings wrote:
> > On Sat, 2018-11-24 at 15:21 +, Simon McVittie wrote:
> > > Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
> > > user-space driver, which is an open source stack if you don't count the
> > > GPU firmware.

> > I installed an AMD RX550 based card last year.  It required updates to
> > the kernel, firmware, X driver, and Mesa, which are all available in
> > stretch-backports.
> 
> Oooh, sounds like you have at least some clue here -- _and_ there are
> non-trivial things one should know.  [...]
> Thus, are there any particular setups you'd recommend for someone running
> unstable and Linus' current kernels?

> 4 nVidia cards that brought me nothing but woe, I wish for something that
> actually works.  And it'd be so nice if instead of having to do the
> research, this here Ben guy told me "do this" so I can return to hacking on
> things that have nothing in common with graphics drivers. :)

Just so this doesn't sound like shoving all effort onto you: even if you
won't provide us with a ready answer on a golden platter, any research is so
much easier if we can start from some advice.  And it's so much better to be
aware of problems _before_ buying stuff.

And it sounds like problems there are.

Thus, knowing what can go bad would be nice for any reader of this list
who's about to look for a GPU.

Which was never a nice thing -- back in the days of Trident/SiS, today
with Mali on ARM or the usual culprits on x86...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄ (funeral doom metal).

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Adam Borowski

On Sat, Nov 24, 2018 at 06:06:16PM +, Ben Hutchings wrote:
> On Sat, 2018-11-24 at 15:21 +, Simon McVittie wrote:
> [...]
> > Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
> > user-space driver, which is an open source stack if you don't count the
> > GPU firmware. It should be comparable to the situation on Intel integrated
> > GPUs (but a lot faster and more featureful, and probably with more bugs,
> > because the hardware is faster and more featureful). Expect to need a
> > recent (buster/sid) kernel, particularly for newer hardware.
> 
> I installed an AMD RX550 based card last year.  It required updates to
> the kernel, firmware, X driver, and Mesa, which are all available in
> stretch-backports.

Oooh, sounds like you have at least some clue here -- _and_ there are
non-trivial things one should know.  As you can tell from my vitriol,
there's no way I'm going to use anything from nVidia -- yet I need to
replace most of my main home box quite badly.

Thus, are there any particular setups you'd recommend for someone running
unstable and Linus' current kernels?

Running -rc kernels is especially unfun if your card requires nVidia's
proprietary drivers (and so are X transitions in unstable).  Nouveau on the
other hand has problems on this own, usually crashes -- some reproducible
(like enabling xfce's compositor), some random.

The card I have right now crashed under load roughly once a week -- until I
got a higher resolution monitor.  Afterwards, the card can handle static
images (editor, browser, ...), but if I try a video or such, it crashes
every ~10 minutes bringing the whole kernel down.  Speak about "replacement
needed urgently"...

But, I don't blame this particular card.  Its predecessor went down in a
fire (thick smoke for the entire room, small but visible actual flame) so
it's likely the PCIe slot is suspect, not worth the risk replacing just the
GPU without a whole new motherboard (I put in an old but unopened card I
happened to have on storage).  I think I get the message this machine is
telling me...

A decade ago, ATI/AMD drivers were abysmal.  If I understand you right,
they have recently massively improved -- for the values of "recently" of
"not yet in Stretch" (which is fine for the likes of us).  After a string of
4 nVidia cards that brought me nothing but woe, I wish for something that
actually works.  And it'd be so nice if instead of having to do the
research, this here Ben guy told me "do this" so I can return to hacking on
things that have nothing in common with graphics drivers. :)

[Not so unrelated to copying in a restaurant. :p]

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Sune Vuorela

On 2018-11-24, Adrian Bunk  wrote:
> libqt5gui5 has > 1k rdeps

I think this is a fact that many people haven't grasped.

And some of those are libraries...

/Sune

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Scott Kitterman

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

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

Scott K

Re: Upcoming Qt switch to OpenGL ES on arm64

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

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

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Adrian Bunk

On Sat, Nov 24, 2018 at 02:40:37PM +0100, Matthias Klose wrote:
> On 24.11.18 11:26, Andy Simpkins wrote:
> >> 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
> 
> so why not keep GL as it is now, and build the GLES packages from a single
> source tarball?  This way you minimize your uploads while having both
> implementations in the archive?  Maybe later on, you could even do the same 
> for
> the 32bit ARM architectures if these are still release architectures by that 
> time.

Putting all KDE packages plus all other Qt-using packages into one 
monster source tarball for building them a second time sounds like
a nightmare impossible to maintain.

Like how would security updates of gst-plugins-good1.0 in stable work
when a second copy of it is in the monster tarball due to gstreamer1.0-qt5?

libqt5gui5 has > 1k rdeps, the sanest way forward for providing two 
different ABI versions of libqt5gui5 at the same time would be two
architectures for arm64.

And that is not a realistic option.

> Matthias

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Ben Hutchings

On Sat, 2018-11-24 at 15:21 +, Simon McVittie wrote:
[...]
> Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
> user-space driver, which is an open source stack if you don't count the
> GPU firmware. It should be comparable to the situation on Intel integrated
> GPUs (but a lot faster and more featureful, and probably with more bugs,
> because the hardware is faster and more featureful). Expect to need a
> recent (buster/sid) kernel, particularly for newer hardware.

I installed an AMD RX550 based card last year.  It required updates to
the kernel, firmware, X driver, and Mesa, which are all available in
stretch-backports.

> Old ATI/AMD GPUs can use the radeon driver stack, which is also open
> source (except for firmware) and comparable to Intel integrated GPUs
> (generally faster and more featureful for hardware of equivalent age).
> 
> I think there might be some intermediate models that are too new for
> radeon but too old for amdgpu; if they exist, those will be stuck with
> the proprietary fglrx driver, which as far as I can tell is like the
> NVidia proprietary driver, but worse. fglrx is no longer supported by
> Debian contrib/non-free.

I'm not aware of any gap.  In fact, at the kernel level, there is some
overlap where the newest models supported by radeon are also supported
(on an opt-in basis) by amdgpu.

The proprietary AMD graphics stack now depends on the amdgpu kernel
driver rather than replacing it.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett




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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Rebecca N. Palmer


Would packaging Regal solve any of this?

https://github.com/p3/regal

It claims to implement OpenGL on top of OpenGL ES, but I don't know if 
it is complete enough or efficient enough to be useful in this context.


Dmitry Shachnev wrote:

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


Would it also break packages that directly call OpenGL functions that 
are not in ES?  e.g. 3D applications that were initially created under 
OpenGL 1 and never completely moved away from the old fixed-function / 
immediate-mode interfaces.


I don't know how many of these there are: the one I know about 
(FlightGear) is already on your list because it also has a GLU 
dependency.  Trying to find them via codesearch (taking the intersection 
of packages matching "glBegin[^A-Z]|glLight|glFog" and 
"path:debian/control libqt|qtbase|qml-module") finds


amarok apitrace aseba avogadro ball bino camitk cgal choreonoid 
clementine cloudcompare colmap connectome-workbench csoundqt digikam 
doomsday dpuser dustrac enki-aseba flightgear fmit fracplanet freecad 
freemat gambas3 gle-graphics gnuradio goldencheetah gr-fosphor 
gst-plugins-good1.0 gudhi hedgewars iannix ifrit imagevis3d itksnap 
klatexformula kstars ksudoku kubrick lazarus leocad libqglviewer 
libreoffice libterralib mame mathgl mcrl2 meshlab mixxx mldemos mlt mm3d 
mudlet mumble obs-studio octave opencolorio openimageio openjfx openms 
openscad openscenegraph openscenegraph-3.4 osmose-emulator otb ovito 
paraview pcl pfstools pianobooster projectm pyqt5 pyqwt3d pyside pyside2 
python-qt4 qt4-x11 qtbase-opensource-src qtiplot qtsvg-opensource-src 
qttools-opensource-src qtwebengine-opensource-src qtwebkit qwtplot3d 
renderdoc retroarch ring sdrangelove shelxle sleepyhead sofa-framework 
soqt soundscaperenderer starpu stellarium structure-synth tulip uranium 
utopia-documents v4l-utils virtualjaguar vite viva vlc vtk6 vtk7 
warzone2100 webcamoid wireshark woo xflr5 yabause


but as some of these are available with a Qt dependency on armel/armhf, 
I suspect they include false positives that use GL1 only in 
optional/example code or contain an embedded copy of the OpenGL headers.

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Rebecca N. Palmer


Lisandro Damián Nicanor Pérez Meyer wrote:

El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:

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.
Wikipedia says Intel GPUs support OpenGL ES 2 since gen3 (~2004)[0] or 
gen4 (~2006)[1] (yes, this is inconsistent), and Nvidia GPUs since NV40 
(~2004)[1] (they don't specify whether this is with Nouveau or 
closed-source Nvidia).  They don't obviously say for ATI/AMD, but the 
Mesa source code says[3] that "all Gallium drivers" (which appear[4][5] 
to include Intel from i915 = ~2004, Nouveau from nv30 = ~2003 and 
ATI/AMD from r300 = ~2002) support GL_ARB_ES2_compatibility.


Simon McVittie wrote:

Try it? The mesa-utils-extra package contains es2gears_x11 and
es2gears_wayland, which appear to be GLES equivalents of glxgears,
and work fine in a GNOME/Wayland environent on my (admittedly much more
recent) Intel integrated GPU.


On my system (Intel gen7, stretch kwin-wayland), both correctly display 
their main animation.  es2gears_x11 has a window frame and responds to 
Esc, but es2gears_wayland doesn't: is that intended, a full-GL window 
manager not being able to add a frame to a GL ES window, or a bug 
somewhere else?


[0] 
https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units ; 
this is based on the Mesa source code [2], though I don't actually know 
if GL_ARB_ES2_compatibility = "can create a full-GL context that 
includes the functionality of ES2 as extensions" implies 
GLX_EXT_create_context_es_profile = "can create a true ES2 context".

[1] https://en.wikipedia.org/wiki/OpenGL_ES
[2] 
https://sources.debian.org/src/mesa/18.2.5-3/src/mesa/drivers/dri/i915/intel_extensions.c/#L84
[3] 
https://sources.debian.org/src/mesa/18.2.5-3/src/mesa/state_tracker/st_extensions.c/#L875

[4] https://sources.debian.org/src/mesa/18.2.5-3/src/gallium/drivers/
[5] https://gallium.readthedocs.io/en/latest/distro.html

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread The Wanderer

On 2018-11-24 at 10:21, Simon McVittie wrote:

> On Sat, 24 Nov 2018 at 15:10:47 +0100, Adam Borowski wrote:
> 
>> I don't have access to any non-embedded Intel cards
> 
> Do those exist? I thought Intel only made GPUs that are integrated
> into their CPUs (the "HD Graphics" series). Presumably that's what
> you meant when you said embedded?

I don't know of any which exist currently, but a naive Google search for
'discrete Intel GPU' turns up news articles from this past August
reporting that they've teased one coming out in ~2020.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

signature.asc
Description: OpenPGP digital signature

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Simon McVittie

On Sat, 24 Nov 2018 at 15:10:47 +0100, Adam Borowski wrote:
> I don't have access to any non-embedded Intel cards

Do those exist? I thought Intel only made GPUs that are integrated into
their CPUs (the "HD Graphics" series). Presumably that's what you meant
when you said embedded?

As far as I understand it the usual PC terminology is that a GPU built
into your CPU (as seen in low-end or ultraportable laptops) is an
"integrated GPU", and a separate module like all(?) NVidia hardware or
most AMD hardware (in gaming/high-end laptops, or a PCIe card in desktops)
is a "discrete GPU". Some AMD CPUs have integrated AMD GPUs.

> Not a clue about AMD stuff.

Recent AMD GPUs use the "amdgpu" kernel driver and its accompanying Mesa
user-space driver, which is an open source stack if you don't count the
GPU firmware. It should be comparable to the situation on Intel integrated
GPUs (but a lot faster and more featureful, and probably with more bugs,
because the hardware is faster and more featureful). Expect to need a
recent (buster/sid) kernel, particularly for newer hardware.

Old ATI/AMD GPUs can use the radeon driver stack, which is also open
source (except for firmware) and comparable to Intel integrated GPUs
(generally faster and more featureful for hardware of equivalent age).

I think there might be some intermediate models that are too new for
radeon but too old for amdgpu; if they exist, those will be stuck with
the proprietary fglrx driver, which as far as I can tell is like the
NVidia proprietary driver, but worse. fglrx is no longer supported by
Debian contrib/non-free.

smcv

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Lisandro Damián Nicanor Pérez Meyer

El sábado, 24 de noviembre de 2018 10:40:37 -03 Matthias Klose escribió:
> On 24.11.18 11:26, Andy Simpkins wrote:
> >> 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
> 
> so why not keep GL as it is now, and build the GLES packages from a single
> source tarball?  This way you minimize your uploads while having both
> implementations in the archive?  Maybe later on, you could even do the same
> for the 32bit ARM architectures if these are still release architectures by
> that time.

Because that single source tarball would alone take more than a day to do a 
test build. At our current maintainer's build/man power, it's unfeasible.



-- 
"No es el crecimiento de la tecnología lo que excluye, sino la
protección sistemática de los derechos de uso de la misma,
lo cual se puede aplicar al arte."
  David Cuartielles

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


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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Lisandro Damián Nicanor Pérez Meyer

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

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

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

Point taken.

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

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

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

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


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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Andy Simpkins

On 24/11/18 14:14, bret curtis wrote:
>>> But even here in this place I have seen *a lot* of "cheap" arm64 boards. 
>>> Yes,
>>> the RPI3[+] is ubiquitous. And having to render Open GL stuff by CPU is
>>> precisely not the fastest thing around.
>>
>>  "I have a Raspberry Pi (or similar mobile class system that
>> has migrated / is migrating away from armel to arm64) and this has
>> forced a move from 'mobile' OpenGLES to 'Desktop' OpenGL.  The result of
>> which is that because that platform (and those like it) do not have
>> hardware acceleration for OpenGL but DO for OpenGLES you think we should
>> change the whole architecture for your use case." 
>>
> 
> This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> if you plan on having hardware accelerated X11 or Wayland, you need
> the VC4 driver. You'll need "Desktop" OpenGL otherwise nothing will
> work on a RPi system, which as of 2015 has over 5 million units
> shipped. This is not an insignificant user base.
> 
> IMHO, the decision to switch away from 'Desktop' OpenGL to GLES was
> the wrong decision and should be reversed until a solution is found to
> support both.
> 
> Cheers,
> Bret
> 

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

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

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

/Andy

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Lisandro Damián Nicanor Pérez Meyer

Hi Andy!

El sábado, 24 de noviembre de 2018 07:26:34 -03 Andy Simpkins escribió:
> On 24/11/2018 02:05, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Andy: explicitly CCing you because I think it answers part of a question
> > you did but in another part of the thread.
> > 
> > El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
> >> On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
> > [snip]
> > 
> >>> Can you build two packages and allow user to select, which one he wants
> >>> to
> >>> install? Or those packages will be binary incompatible?
> >> 
> >> That's a good question, yes. It'w ahst I was wondering too.
> > 
> > And that's a perfectly valid question, one we did in 2015, Ubuntu tried
> > out
> > (as Dmitry pointed out) and did not work.
> > 
> > Why?
> > 
> > Short story: really *too* complicated and error prone.
> > 
> > Long story:
> > 
> > Please first check this image:
> > 
> > 
> > 
> > That's almost all of Qt for 5.10 (we have now new submodules, so I need to
> > update it).
> 
> Understood
> 
> > The Desktop/GLES decision is done at the root of the graph, qtbase. This
> > decision changes the API/ABI of libqt5gui5, one of the libraries provided
> > by qtbase.
> 
> Ack
> 
> > So, as the API/ABI changes then we would need to (probably) ship two set
> > of
> > headers and (for sure) two different libraries, let's say libqt5gui5 for
> > Desktop and libqt5gui5gles for GLES.
> 
> Yes that sounds right
> 
> > But it doesn't ends there. The whole graph you saw is actually the
> > *entire*
> > Qt. Upstream provides it either as a big fat tarball or as submodules. We
> > took the submodules route because building the whole tarball as one would
> > take literally days in slow arches.
> 
> The time taken for an automated process to run (or fail) should not be a
> justification not to do something.
> We need to be able to build the entire archive, not just Qt, and this is
> an automated process.

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

> As an aside: The current arm64 buildd's are plenty fast enough to build
> the entire archive in a few days (IIRC sledge has done this several
> times recently), I also believe that the buildds (and porter boxes?) are
> being (have been?) replaced with newer and faster boxes (also easier for
> DSA to maintain).
> I believe that they are also able to build / will build native armhf
> (and armel).  It is my understanding bug reports & fixes are in progress
> 
> > And a single mistake could be disastrous.
> 
> Not relevant - a single mistake in any package is called a bug. As a
> distribution we have many of these; we strive not to introduce new ones
> and fix those that we can...
>
> > Now whatever switch is applied to qtbase it's "inherited" by the rest of
> > the submodules. So if we ship two versions of libqt5gui5 then we would
> > probably need to ship two versions of the libs provided by qtdeclarative,
> > which is affected by this switch.
> 
> Absolutely - everything in the subsystem would need to be duplicated
> up-to the point of common API
> 
> > This waterfall schema means *multiple* libraries would have to start doing
> > this two-binaries thing, as Ubuntu devs discovered. But remember that Qt
> > is
> > really a set of submodules, so in any later version any submodule could
> > start using this switch for something. So whatever change could mean yet
> > another set of binaries with a transition with multiple rebuilds of the
> > big part of rdeps of Qt... no, we don't want to enter that mess.
> 
> No. The libraries do not need to have any knowledge about the other
> subsystem / collection of sub modules. i.e. 'desktop' does not need to
> be aware of 'mobile' and vis versa.

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

> > So we either keep the status quo of keeping arm64 in Desktop GL or switch
> > to GLES. The question is: which use case gives more benefit for our users
> > for the next stable release?
> > 
>  So far I personally know 0 people with an arm64 board with PCI slots,
>  while I know many with arm64 boards with hardware GLES support.
> >>> 
> >>> I'm working with big arm64 iron, so for me a server arm64 board with
> >>> PCIe
> >>> slots (and thus PCIe graphic cards) and on-board Aspeed "VGA card" is
> >>> more
> >>> common compared to GLES-enabled arm64 SoC.
> > 
> > How many Qt-based applications do you use there? Which ones use OpenGL?
> > 
> >> Yeah - it depends exactly on your background. There's a small (but
> >> growing) set of arm64 desktop users, and it would be unfortunate to
> >> cut them off.
> > 
> > Let's be fair: I

Re: Upcoming Qt switch to OpenGL ES on arm64

Hello Lisandro!

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

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

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

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

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

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

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

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

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

Cheers,
Bret

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

Re: Upcoming Qt switch to OpenGL ES on arm64

> > But even here in this place I have seen *a lot* of "cheap" arm64 boards. 
> > Yes,
> > the RPI3[+] is ubiquitous. And having to render Open GL stuff by CPU is
> > precisely not the fastest thing around.
>
>  "I have a Raspberry Pi (or similar mobile class system that
> has migrated / is migrating away from armel to arm64) and this has
> forced a move from 'mobile' OpenGLES to 'Desktop' OpenGL.  The result of
> which is that because that platform (and those like it) do not have
> hardware acceleration for OpenGL but DO for OpenGLES you think we should
> change the whole architecture for your use case." 
>

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

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

Cheers,
Bret

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Adam Borowski

On Sat, Nov 24, 2018 at 01:09:35PM +, Simon McVittie wrote:
> On Fri, 23 Nov 2018 at 23:12:19 -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> > > 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.
> 
> Try it? The mesa-utils-extra package contains es2gears_x11 and
> es2gears_wayland, which appear to be GLES equivalents of glxgears,
> and work fine in a GNOME/Wayland environent on my (admittedly much more
> recent) Intel integrated GPU.

Tested on an early bronze age i386 box with an "82915G/GV/910GL"; both
glxgears and es2gears_x11 work fine.  I don't think anyone is going to run a
modern desktop environment on a machine older than that.

But that's an Intel card -- with nVidia, stuff 3 years old gets dropped from
the official drivers while 2 years old doesn't get Linux support yet -- and
nouveau has problems on its own.

I don't have access to any non-embedded Intel cards so I can't test one in
an arm64 box with a PCIe slot. ;)  But despite apparent insanity of such an
idea, it might be actually the sanest option.

Not a clue about AMD stuff.

Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Matthias Klose

On 24.11.18 11:26, Andy Simpkins wrote:
>> 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

so why not keep GL as it is now, and build the GLES packages from a single
source tarball?  This way you minimize your uploads while having both
implementations in the archive?  Maybe later on, you could even do the same for
the 32bit ARM architectures if these are still release architectures by that 
time.

Matthias

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Simon McVittie

On Fri, 23 Nov 2018 at 23:12:19 -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> > 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.

Try it? The mesa-utils-extra package contains es2gears_x11 and
es2gears_wayland, which appear to be GLES equivalents of glxgears,
and work fine in a GNOME/Wayland environent on my (admittedly much more
recent) Intel integrated GPU.

(Of course, you can't expect es2gears_wayland to work in a pure X11
environment, unless you install and run weston, which has an X11 backend
that can be used to provide a Wayland display nested in an X11 window,
like a Wayland equivalent of Xephyr or Xnest.)

smcv

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Andy Simpkins




On 24/11/2018 02:05, Lisandro Damián Nicanor Pérez Meyer wrote:

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

El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:

On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:

[snip]

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

That's a good question, yes. It'w ahst I was wondering too.

And that's a perfectly valid question, one we did in 2015, Ubuntu tried out
(as Dmitry pointed out) and did not work.

Why?

Short story: really *too* complicated and error prone.

Long story:

Please first check this image:



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

Understood


The Desktop/GLES decision is done at the root of the graph, qtbase. This
decision changes the API/ABI of libqt5gui5, one of the libraries provided by
qtbase.

Ack


So, as the API/ABI changes then we would need to (probably) ship two set of
headers and (for sure) two different libraries, let's say libqt5gui5 for
Desktop and libqt5gui5gles for GLES.

Yes that sounds right


But it doesn't ends there. The whole graph you saw is actually the *entire*
Qt. Upstream provides it either as a big fat tarball or as submodules. We took
the submodules route because building the whole tarball as one would take
literally days in slow arches.
The time taken for an automated process to run (or fail) should not be a 
justification not to do something.
We need to be able to build the entire archive, not just Qt, and this is 
an automated process.


As an aside: The current arm64 buildd's are plenty fast enough to build 
the entire archive in a few days (IIRC sledge has done this several 
times recently), I also believe that the buildds (and porter boxes?) are 
being (have been?) replaced with newer and faster boxes (also easier for 
DSA to maintain).
I believe that they are also able to build / will build native armhf 
(and armel).  It is my understanding bug reports & fixes are in progress




And a single mistake could be disastrous.
Not relevant - a single mistake in any package is called a bug. As a 
distribution we have many of these; we strive not to introduce new ones 
and fix those that we can...

Now whatever switch is applied to qtbase it's "inherited" by the rest of the
submodules. So if we ship two versions of libqt5gui5 then we would probably
need to ship two versions of the libs provided by qtdeclarative, which is
affected by this switch.
Absolutely - everything in the subsystem would need to be duplicated 
up-to the point of common API

This waterfall schema means *multiple* libraries would have to start doing
this two-binaries thing, as Ubuntu devs discovered. But remember that Qt is
really a set of submodules, so in any later version any submodule could start
using this switch for something. So whatever change could mean yet another set
of binaries with a transition with multiple rebuilds of the big part of rdeps
of Qt... no, we don't want to enter that mess.


No. The libraries do not need to have any knowledge about the other 
subsystem / collection of sub modules. i.e. 'desktop' does not need to 
be aware of 'mobile' and vis versa.




So we either keep the status quo of keeping arm64 in Desktop GL or switch to
GLES. The question is: which use case gives more benefit for our users for the
next stable release?


So far I personally know 0 people with an arm64 board with PCI slots,
while I know many with arm64 boards with hardware GLES support.

I'm working with big arm64 iron, so for me a server arm64 board with PCIe
slots (and thus PCIe graphic cards) and on-board Aspeed "VGA card" is more
common compared to GLES-enabled arm64 SoC.

How many Qt-based applications do you use there? Which ones use OpenGL?


Yeah - it depends exactly on your background. There's a small (but
growing) set of arm64 desktop users, and it would be unfortunate to
cut them off.

Let's be fair: I live almost at the end of the world, probably at very least
600 km away from the next DD and in a country in which buying new hardware
it's not exactly the easiest thing (my current machine, currently the only one
I have working, is now 10 years old...). So yes, as Steve says, it depends on
your background.

But even here in this place I have seen *a lot* of "cheap" arm64 boards. Yes,
the RPI3[+] is ubiquitous. And having to render Open GL stuff by CPU is
precisely not the fastest thing around.


Right so this is the crux of the matter.

I am putting words in your mouth here - please accept my apologies I am 
trying to describe how I have perceived your comments, this is clearly 
not the words you have used but that is how I am parsing them.  I have 
tried several times to re-word tjis better, it still feels 
confrontational but

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-23 Thread Lisandro Damián Nicanor Pérez Meyer

Hi Bret!

El viernes, 23 de noviembre de 2018 11:14:34 -03 psi...@gmail.com escribió:
> 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
[snip]

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


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



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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-23 Thread Lisandro Damián Nicanor Pérez Meyer

El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote:
> > W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> > > 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
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-23 Thread Lisandro Damián Nicanor Pérez Meyer

Hi Wookey!

El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote:
> > Hello,
> > 
> > > - 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?

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

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

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-23 Thread 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.

El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
> On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
[snip]
> >Can you build two packages and allow user to select, which one he wants to
> >install? Or those packages will be binary incompatible?
> 
> That's a good question, yes. It'w ahst I was wondering too.

And that's a perfectly valid question, one we did in 2015, Ubuntu tried out 
(as Dmitry pointed out) and did not work.

Why?

Short story: really *too* complicated and error prone.

Long story:

Please first check this image:

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

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?

> >> So far I personally know 0 people with an arm64 board with PCI slots,
> >> while I know many with arm64 boards with hardware GLES support.
> >
> >I'm working with big arm64 iron, so for me a server arm64 board with PCIe
> >slots (and thus PCIe graphic cards) and on-board Aspeed "VGA card" is more
> >common compared to GLES-enabled arm64 SoC.

How many Qt-based applications do you use there? Which ones use OpenGL?

> Yeah - it depends exactly on your background. There's a small (but
> growing) set of arm64 desktop users, and it would be unfortunate to
> cut them off.

Let's be fair: I live almost at the end of the world, probably at very least 
600 km away from the next DD and in a country in which buying new hardware 
it's not exactly the easiest thing (my current machine, currently the only one 
I have working, is now 10 years old...). So yes, as Steve says, it depends on 
your background.

But even here in this place I have seen *a lot* of "cheap" arm64 boards. Yes, 
the RPI3[+] is ubiquitous. And having to render Open GL stuff by CPU is 
precisely not the fastest thing around.

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?

-- 
She got her good looks from her father. He's a plastic surgeon.
 -- Groucho Marx

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-23 Thread Wookey

On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote:
> Hello,
> > - 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
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-23 Thread psi29a

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 6.3.2 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAQBQJb+AtICRDCN3t9WEy5MAAAaK8QAIKCkxpHlsI2uVB+K9HE
g1RFUShdMJWUtjgIZ6ngNshB1vqzbzQd6zOAxkJGo8ydO5yFYiIOtlc9pODx
rUZOLob9M+XLkB5ISrYuNtOF22CpRreKhvFV8dDxiUkRLd6AI6G39KubpB/w
WVYNFldg5u0CweGabUIBxKvkdS9NKSMMPbtSDsZP/jpNrRIxqX8rU3WfZfPu
x7LPJGG7lNRzAAIAcZTphhbW+mlFfaxVXw5Qt0WLuhDDr8WLoM65SNHL5Zox
mHTxVfoGDQoQv0OnL1ytqBpSLEksq7lZC3D+5XpjvxM8rPAVCk0Sa6FZ6mUy
g6ktvP0BmWb/M+CfyzPYocfyD5VJMAXtVhc2KqC0AmlWgggGph8YxWkHK3yW
dYxf9P65FBPtx4y5oX5OqVbvRPaLcOk9q8AgciAPZi1RgWqfou02wKCQqICk
N2Un/8RUhJUfHBHxTusbLLqLLFtIw6VVwqoIed3jIFCjUP0QJCh/Nwk4UpxK
714mxFVuJoaYFHQvLJOak8WbsDU6eGfs04sHM5AAfwJdO9pDRcKTMCP/Q4SC
9Nvc/dYQpoXn+AAFvEHqPZKHYkngwQD2vijrwduD6Iu2eehVMnM4ck5FDDwg
+QNiZCukrkg2iayn/xrwguEtPmI8acK2ttCEElij38kOzIVsPyO6n3Je55Ax
ZRKC
=7v54
-END PGP SIGNATURE-

Re: Upcoming Qt switch to OpenGL ES on arm64

On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote:
> W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> > 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


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

On Fri, Nov 23, 2018 at 12:25:51PM +0100, Julien Cristau wrote:
> > 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


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-23 Thread Marcin Juszkiewicz

W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> 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.

Re: Upcoming Qt switch to OpenGL ES on arm64

On Fri, Nov 23, 2018 at 09:34:44AM +, Andy Simpkins wrote:
> 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


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

On Thu, Nov 22, 2018 at 06:01:14PM -0500, Gene Heskett wrote:
> 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

signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-23 Thread Julien Cristau

On 11/23/18 12:18 PM, Dmitry Shachnev wrote:
> On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote:
>> 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

Re: Upcoming Qt switch to OpenGL ES on arm64