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

On Tuesday 27 November 2018 02:04:33 Luke Kenneth Casson Leighton wrote:

> On Tue, Nov 27, 2018 at 6:47 AM Gene Heskett  
wrote:
> > On Monday 26 November 2018 22:04:04 Luke Kenneth Casson Leighton 
wrote:
> > > 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.
> >
> > If they choose to support it, I've found most are in it for the
> > initial sale, and its up to you to make it do useful work. This
> > seems to be the case with the rock64's, Odroids and such, very close
> > to zero support,
>
>  the odroids, i know they're a very small team in korea: you cannot
> expect "support".   the contract: you bought the hardware, therefore
> you know what you're doing.
>
> rock64, that's TL Lim's baby: he's doing a hell of a lot of work
> behind the scenes to get GPL compliance from Allwinner and much more.
>  TL's team do the best they can by providing forums for people to use
> and to support each other.
>
>  ultimately, though, if you've the money (if you place an order for
> 10k units for example), that will get their immediate attention.  if
> not... then, well, the reality is: every "support" call or email or
> forum message answered is profit lost.
>
>  that's just how it is.  you want better, be prepared to pay the
> money.
>
> > Pi's are buckets better,
>
>  better because the GPU is proprietary and Broadcom should be
> financially supported and we should all buy their products, thus
> keeping them in business and sustaining and endorsing Broadcom's
> unethical practices?
>
I'm quite familiar with broadcoms lack of support, its excrementy at 
best. I bought a lappy, $1300, many years ago now, advertised as having 
a builtin radio.  Came with xp installed, but that got wiped in favor of 
Mandrake when I found that not even the windows supplied driver could 
make that bcm4318 radio work. Now with Mate 17 on it, that radio still 
doesn't work.

>  and, because they are "better", debian should also prioritise
> supporting Broadcom's unethical practices by making a
> mutually-exclusive decision that chops off alternatives that *are*
> libre?

Not in that light, but would sinking the pi foundation make us look any 
better? I think not. But I'm not trying to white wash them either. IP 
theft is the mode of the times it seems. But,if you want a high 
performance gpio that can run a short spi bus at 50 megabaud, where else 
are you going to get it besides broadcom? TANSTAAFL is an unbreakable 
law, just like C speed.

>  ... you see how that works?  the wrong decision here, debian gets to
> completely destroy what is already a fragile ecosystem, just for
> "convenience".

There is also TANSTAAFL. But you will do as pure as you can and according 
to the debian bylaws, and I admire that greatly, its a very large part 
of why I'm here. But you did ask the question, and I gave you 2 cents 
worth of the real world where we need to just get the job done to the 
best of the hardware's ability. And "we" are not doing a very good job 
of exploiting the hardware we can buy today.

But I've said my piece, so won't hassle you about it anymore in this 
thread. I might still complain even, but thats how it is. And its not 
your fault so please don't take it personal, its certainly not intended 
to be.

Take care and stay well, Luke Kenneth Casson Leighton.

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread Luke Kenneth Casson Leighton

On Tue, Nov 27, 2018 at 6:47 AM Gene Heskett  wrote:
>
> On Monday 26 November 2018 22:04:04 Luke Kenneth Casson Leighton wrote:
>
> > 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.
>
> If they choose to support it, I've found most are in it for the initial
> sale, and its up to you to make it do useful work. This seems to be the
> case with the rock64's, Odroids and such, very close to zero support,

 the odroids, i know they're a very small team in korea: you cannot
expect "support".   the contract: you bought the hardware, therefore
you know what you're doing.

rock64, that's TL Lim's baby: he's doing a hell of a lot of work
behind the scenes to get GPL compliance from Allwinner and much more.
 TL's team do the best they can by providing forums for people to use
and to support each other.

 ultimately, though, if you've the money (if you place an order for
10k units for example), that will get their immediate attention.  if
not... then, well, the reality is: every "support" call or email or
forum message answered is profit lost.

 that's just how it is.  you want better, be prepared to pay the money.

> Pi's are buckets better,

 better because the GPU is proprietary and Broadcom should be
financially supported and we should all buy their products, thus
keeping them in business and sustaining and endorsing Broadcom's
unethical practices?

 and, because they are "better", debian should also prioritise
supporting Broadcom's unethical practices by making a
mutually-exclusive decision that chops off alternatives that *are*
libre?

 ... you see how that works?  the wrong decision here, debian gets to
completely destroy what is already a fragile ecosystem, just for
"convenience".

l.

Re: Upcoming Qt switch to OpenGL ES on arm64

On Monday 26 November 2018 22:04:04 Luke Kenneth Casson Leighton wrote:

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

If they choose to support it, I've found most are in it for the initial 
sale, and its up to you to make it do useful work. This seems to be the 
case with the rock64's, Odroids and such, very close to zero support, 
Pi's are buckets better, yet the pi has hardware specs and design 
compromises that can seriusly impact its performance. Only two data 
paths in the pi skip the internal usb2 hub it uses to do most it its 
i/o, one is the radio for wifi, the other is the gpio/spi. Everything 
else has to fight for a turn at getting thru that slow hub, which 
translates to millions of keyboard and mouse events being thrown away. 
Its too busy.

Fortunately, when that gets to be too painfull, a reboot or sometimes 5 
will eventually arrive at a condition where the mouse and keyboard Just 
Works(TM). And then it works till the next power failure which may be 
several months. Both pi and rock64 uptimes are excellent.
>
> 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.
>
> l.



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

Re: Upcoming Qt switch to OpenGL ES on arm64

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: Upcoming Qt switch to OpenGL ES on arm64

On Monday 26 November 2018 16:16:40 Alan Corey wrote:

> I think not pulling it to full screen puts everybody in the same boat
> by using the default size.

It also hands you figures not achievable in the real world, often off by 
20x.

> But I can watch videos with smplayer on my 
> Rock64, on a Pi I need to use omxplayer because smplayer is too low.
> There was some mention on the pine64.org page about using the Rock64
> as a multimedia machine.

Seems so, sadly.

> Ah, does linuxcrc do any kind of video acceleration?  Never seen it.
> It could with DRI I think.

No, its gui is pretty simple, depending only on a basic x server thats 
fast enough to keep up with the machines movements. The rpi3b fails that 
speed rather spectacularly with its frame buffer video.

I could post a screen snapshot but I believe the listserver strips them.

DRI is generally fast enough on the intel atom powered boxes, and their 
irq response it outstanding. Unforch the good intel board, the D525MW 
was discoed 5 years ago and the supply lines drained rapidly.

Where its super critical is in the response time and consistency of that 
time, to a scheduled interrupt, which may be at 25 microsecond intervals 
if you are driveing stepper motors in software. If that 25 u-second time 
wobbles by 5 u-secs, it can play hob with a stepper motors available 
torque.

Many of us use fpga cards to offload that from the computer, but they 
also add from $120 to $300 to the cost of building a usable machine. 

Getting that stepper drive job off the cpu means the rest of it can be 
done in a 1 millisecond thread, and some of what I am doing on a big 
lathe can be done in a 200 hz thread, which is how I move the machine 
manually since the CNC replaces any hand cranks the machine may have had 
when it was new, some of them up to 100 years old, with encoder dials 
such as the $20 one from mpja.com. I use 2 of them on that 70 yo 
Sheldon. Works nice, to an accuracy of .0001". And I can electronicly 
adjust the per click distance up to twenty thou per click, which can 
drive the machine faster than it can move if I spin the knob fast.

So 2 requirements, if satisfied, lets these little credit card computers 
run LinuxCNC well.

1. rt-preempt (or full rtai) patched kernel. Usually pinned to keep apt 
from installing a newer kernel that is NOT suitably patched.

2. A usable speed SPI interface, which the pi is outstanding at, I am 
writing 32 bit packets to that interface card at 42 megabaud, and 
receiving its replies at 25 megabaud. Whether that can be done on the 
rock64's I have remains to be seen. The driver that does that is 
rpspi.ko, and its written specifically for the pi3b.  Part of the LCNC 
install these days.

3. usable real world video speeds, 20 fps or more for full screen 
refresh.

4. We don't care about audio, we probably wouldn't hear it over the noise 
of the machine anyway. :-)

Thanks Alan.

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-26 Thread Alan Corey

I think not pulling it to full screen puts everybody in the same boat
by using the default size.  But I can watch videos with smplayer on my
Rock64, on a Pi I need to use omxplayer because smplayer is too low.
There was some mention on the pine64.org page about using the Rock64
as a multimedia machine.

Ah, does linuxcrc do any kind of video acceleration?  Never seen it.
It could with DRI I think.

On 11/26/18, Gene Heskett  wrote:
> On Monday 26 November 2018 09:40:34 Alan Corey wrote:
>
>> 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.
>
> glxgears is all I have, on both an rpi3b and a rock64
>
> But lets be realistic, what good is either if not pulled out to full
> screen?,
>
> Here, on the rpi3b its less than 1 FPS! This is because the realtime
> kernal is pinned to keep apt from replacing it with something that
> linuxcnc won't run on. With the actual size of lcnc's gui being about
> 1/2 screen I get about 4 FPS for a refresh rate on a 1920 by 12xx
> monitor. But because the backplot is so slow anything that smells like a
> collision with a fixture is done really slow, else the collision will
> have already happened long before I can take corrective action
>
> On the rock64, its around 4.5 FPS near full screen, rangeing up to 35 at
> its launch it size, on a 1366x768 monitor.
>
> I have other machines running on intel x86 hardware that give me
>
> close enough to real time its not been a problem. So videowise, on the
> arms, I could use every bit of help I can get.
> .
>> 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/
>
>
>
> --
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
>
>


-- 
-
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: Upcoming Qt switch to OpenGL ES on arm64

On Monday 26 November 2018 09:40:34 Alan Corey wrote:

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

glxgears is all I have, on both an rpi3b and a rock64

But lets be realistic, what good is either if not pulled out to full 
screen?,

Here, on the rpi3b its less than 1 FPS! This is because the realtime 
kernal is pinned to keep apt from replacing it with something that 
linuxcnc won't run on. With the actual size of lcnc's gui being about 
1/2 screen I get about 4 FPS for a refresh rate on a 1920 by 12xx 
monitor. But because the backplot is so slow anything that smells like a 
collision with a fixture is done really slow, else the collision will 
have already happened long before I can take corrective action

On the rock64, its around 4.5 FPS near full screen, rangeing up to 35 at 
its launch it size, on a 1366x768 monitor.

I have other machines running on intel x86 hardware that give me
  
close enough to real time its not been a problem. So videowise, on the 
arms, I could use every bit of help I can get.
.
> 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/



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

Re: Upcoming Qt switch to OpenGL ES on arm64

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

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

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

2018-11-26 Thread Raphael Hertzog

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

2018-11-24 Thread Gene Heskett

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

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

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

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

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

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

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

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

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Steve McIntyre

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

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-24 Thread Gene Heskett

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

> > > But even here in this place I have seen *a lot* of "cheap" arm64
> > > boards. Yes, the RPI3[+] is ubiquitous. And having to render Open
> > > GL stuff by CPU is precisely not the fastest thing around.
> >
> >  "I have a Raspberry Pi (or similar mobile class system
> > that has migrated / is migrating away from armel to arm64) and this
> > has forced a move from 'mobile' OpenGLES to 'Desktop' OpenGL.  The
> > result of which is that because that platform (and those like it) do
> > not have hardware acceleration for OpenGL but DO for OpenGLES you
> > think we should change the whole architecture for your use case."
> > 
>
> This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> if you plan on having hardware accelerated X11 or Wayland, you need
> the VC4 driver. You'll need "Desktop" OpenGL otherwise nothing will
> work on a RPi system, which as of 2015 has over 5 million units
> shipped. This is not an insignificant user base.
>
That was 2015? I would at least triple that figure now. I bought 3, 2 
years ago, blew one, and still have 2. I went to buy two more a few 
months back, sold out. More on order.  So that project got put on hold.

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

+1

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

> Cheers,
> Bret



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

Re: Upcoming Qt switch to OpenGL ES on arm64

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

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

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

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

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

Because it would require two flavours of all users.

/Sune

Re: Upcoming Qt switch to OpenGL ES on arm64

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

On 2018-11-23, Julien Cristau  wrote:
> Why is it OK to break them on arm64 if it's not OK to break them on
> amd64?  Do you have a list of those packages?

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

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

For each arch the Qt maintainers have the choice

1) gles
2) desktop gl

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

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

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

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

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

/Sune

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

2018-11-23 Thread Stefan Monnier

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

Apparently none of them are here, tho.

> and it would be unfortunate to cut them off.

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

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


Stefan

Re: Upcoming Qt switch to OpenGL ES on arm64

2018-11-23 Thread Gene Heskett

On Friday 23 November 2018 06:37:28 Dmitry Shachnev wrote:

> 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

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

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

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

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

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

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

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

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