Re: Upcoming Qt switch to OpenGL ES on arm64

[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

[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

[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

[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

[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: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Raphael Hertzog]

Hello Lisandro,

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

On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> It seems now clear that the general consensus seems to expect:
> = Qt available for both Desktop and ES OpenGL flavours
> = If no change is possible, keep arm64 with Desktop OpenGL support

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


signature.asc
Description: PGP signature

Re: Upcoming Qt switch to OpenGL ES on arm64

[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

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

l.

Re: Upcoming Qt switch to OpenGL ES on arm64

[Gene Heskett]

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

[Gene Heskett]

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

[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: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Stefan Monnier]

>> Both Dmitry and I just learned that the RPI has the VC4 driver which enables
>> it to do hardware acceleration for Desktop OpenGL, we must admit that this is
>> a game changer in many ways, even if we are talking on just one board (but
>> quite an ubiquitous one).
> I expect this also applies to any driver in (or soon to be in) mesa,
> including freedreno (Qualcomm), panfrost (Mali), lima (Mali), Etnaviv
> (Vivante), Tegra etc. Drivers only supporting GLES seems to be a
> something that happens only with the proprietary drivers.

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


Stefan

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

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
> Hello Lisandro,
> 
> TLDR: thank you for starting this discussion, it was required as it's not
> an easy decision to take as there is no realistic perfect solution,

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

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

Will "kind of" do. Read below.


> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It seems now clear that the general consensus seems to expect:
> > = Qt available for both Desktop and ES OpenGL flavours
> > = If no change is possible, keep arm64 with Desktop OpenGL support
> 
> I'm not pleased with how this discussion was handled. First of all,
> you did not leave enough time for all stakeholders to participate in
> the discussion (started on November 22th, closed November 25th, 3 days,
> that's not a reasonable timeframe in particular when 2 of the 3 days
> were in the week-end).

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

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

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

So:

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

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

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

Regards, Lisandro.

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


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

Re: Upcoming Qt switch to OpenGL ES on arm64

[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

[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

proposta ordine

[Vanessa De Rose]

Ciao,
Ti piacerebbe aumentare SUBITO i tuoi followers sul tuo profilo instagram ?
Se ancora non hai provato il nostro servizio di vendita followers è questo il 
momento buono !
Abbiamo pensato di estendere ad oggi gli sconti del blackfriday e puoi 
acquistare i nostri pacchetti SOLO OGGI con il 30 % di sconto !

Vai su http://bit.ly/IncrementaFollowers e inserisci il codice sconto 
"blackfriday"

Aumenta subito la tua fanbase e porta al top il tuo profilo Instagram!

Alessia De Rose | account Instamore 

Re: Upcoming Qt switch to OpenGL ES on arm64

[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

[Gene Heskett]

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: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Jonas Smedegaard]

Quoting Raphael Hertzog (2018-11-26 12:37:57)
> Software can be fixed/improved to also work with OpenGL ES. However 
> hardware, once bought, cannot be fixed to support Desktop OpenGL when 
> it has been designed for OpenGL ES only.

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

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


 - Jonas

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

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


signature.asc
Description: signature

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

[Riku Voipio]

On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote:
> were in the week-end). I was aware of the discussion but did not
> had the time to chime in, yet I was the person who re-opened the bug
> #881333 in the first place.
 
> I also invited someone else who is working on a concrete project involving
> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
> now but he also did not have the time to contribute to the discussion.

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

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

https://gitlab.freedesktop.org/panfrost

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

Riku

Information ASMDA2019 International Conference and DEMOGRAPHICS2019 Workshop

[secretar]

Dear Colleague, 

You are kindly invited to participate and to submit an Abstract, Paper,
Invited Talk and/or an Invited Session (3-6 papers) to the forthcoming
Applied Stochastic Models and Data Analysis International Conference
(ASMDA2019) and the Demographics2019 Workshop (11-14 June 2019, Florence,
Italy,  http://www.asmda.es ). The venue is in Grand Hotel Adriatico in a
central place of Florence with many nearby attractions and accommodation
places.

 

Proposals for Plenary and Keynote talks are welcomed.

 

Note that the ASMDA and SMTDA Conferences started many years earlier (the
first ASMDA was organized in 1981 in Brussels, Belgium) and our email lists
include old and new addresses.

It is a very important task to update our lists. If you would like to remove
your email address from our conference lists, please click here: Unsubscribe
  

If you like to add a new address, please click here: Add New email Address
  and add your email
address in the Subject line.

 

The publications of the conference include:

1. The Book of Abstracts in Electronic and in Paper form

2. Electronic Proceedings in the web in a permanent website

3. Publications in International Journals

4. Publications in edited Books

 

For more information and Abstract/Paper submission and Special and Invited
Session Proposals please visit the conference website at:
http://www.asmda.es/asmda2019.html or send email to
 secretar...@asmda.com 

-The same event will host the Demographics2019 International Workshop
(http://www.asmda.es/demographics2019.html ). The main focus in on Health
State and the optimal retirement age.

 

Best regards

 

On behalf of the Conference Committee

 

The Conference Secretariat

___

New Book on “Exploring the Health State of a Population by Dynamic Modeling
Methods”

This is the 45 Volume of the Springer Series on Demographic Methods and
Population Analysis  

 

New Book on “Demography and Health Issues: Population Aging, Mortality and
Data Analysis”

This is the 46 Volume of the Springer Series on Demographic Methods and
Population Analysis  

 

Several ASMDA publications are already in the market starting from the
Kluwer publication of 1995 now provided by Springer 

Whereas the “Advances in Stochastic Modelling and Data Analysis” in
Birkhäuser (2010) has more than 57000 downloads in the e-edition.

https://www.springer.com/us/book/9780817647988https://www.springer.com/us/bo
ok/9780817647988
 

 

More details and documentation from
http://www.asmda.es/demographics2019.html 

 


_

 

 

ASMDA and SMTDA Conferences

 

ASMDA 1981 Brussels, Belgium

ASMDA 1983 Brussels, Belgium

ASMDA 1985 Brussels, Belgium

ASMDA 1988 Nancy, France

ASMDA 1991 Granada, Spain

ASMDA 1993 Chania, Crete, Greece

ASMDA 1995 Dublin, Ireland

ASMDA 1997 Anacapry, Italy

ASMDA 1999 Lisbon, Portugal

ASMDA 2001 Compiègne, France

ASMDA 2005 Brest, France

ASMDA 2007 Chania, Crete, Greece

ASMDA 2009 Vilnius, Lithuania

SMTDA 2010 Chania, Crete, Greece

ASMDA 2011 Rome, Italy

SMTDA2012 Chania, Crete, Greece

ASMDA 2013 Mataró (Barcelona), Spain

SMTDA2014 Lisbon, Portugal

ASMDA 2015 Piraeus, Greece

SMTDA 2016 Valletta, Malta

ASMDA 2017 De Morgan House, London, UK

SMTDA2018 Chania, Crete, Greece

ASMDA2019 Florence, Italy

 

 

__

If you don't like to receive messages regarding the SMTDA2018 Conference,
please click here: Unsubscribe
 

 

 

 

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

[Alan Corey]

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

On 11/26/18, Lisandro Damián Nicanor Pérez Meyer  wrote:
> El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
>> Hello Lisandro,
>>
>> TLDR: thank you for starting this discussion, it was required as it's not
>> an easy decision to take as there is no realistic perfect solution,
>
> Our (team-wide) pleasure. This is something we have been digging since
> 2015.
>
>> but I
>> believe you took the wrong decision. Please consider deferring the
>> decision to the technical committe by seeking his advice (point 6.1.3
>> of the constitution
>> https://www.debian.org/devel/constitution.en.html#item-6).
>
> Will "kind of" do. Read below.
>
>
>> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
>> > It seems now clear that the general consensus seems to expect:
>> > = Qt available for both Desktop and ES OpenGL flavours
>> > = If no change is possible, keep arm64 with Desktop OpenGL support
>>
>> I'm not pleased with how this discussion was handled. First of all,
>> you did not leave enough time for all stakeholders to participate in
>> the discussion (started on November 22th, closed November 25th, 3 days,
>> that's not a reasonable timeframe in particular when 2 of the 3 days
>> were in the week-end).
>
> My most sincere apologies if our timeframe do not fit yours.
>
> Now, wrt the decision: clearly the situation is very complex, involving many
>
> different kinds of arm64 devices, drivers, libraries et all. People involved
>
> have different opinions. We so far have been the proxy between them, be it
> on
> bugs, IRC or whatever other channels our users have to contact us. We prefer
>
> not to be this proxy anymore (again, read below).
>
> Besides we (Qt's team) have just learned that the Desktop/ES support is not
>
> tied to the hardware but to the driver. That's a particularly interesting
> point.
>
> So:
>
> To quote my original mail, the "Qt available for both Desktop and ES OpenGL
>
> flavours" point remains unchanged: if someone wants to make it happen [s]he
>
> must join the team and support it from the inside. Remember there are little
>
> chances for this to happen in time for Buster.
>
> For the second point, "If no change is possible, keep arm64 with Desktop
> OpenGL support", we have this position: we will keep the status quo,
> deferring
> users who want GLES support to Ubuntu.
>
> *But* we are open to change this for any arch (read it: support either one
> or
> the other technology) as long as the decision is taken by the technical
> committee. As I wrote before, we will keep the status quo, so if anyone is
> interested in any change feel free to contact the TC.
>
> Regards, Lisandro.
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>


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

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

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 26 de noviembre de 2018 14:21:25 -03 Alan Corey escribió:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program?

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

> Supply both libraries?

Already answered in the thread.

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


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

Re: Upcoming Qt switch to OpenGL ES on arm64

[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

[Gene Heskett]

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: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Steve Langasek]

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

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

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

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

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

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

> On 11/26/18, Lisandro Damián Nicanor Pérez Meyer  wrote:
> > El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
> >> Hello Lisandro,
> >>
> >> TLDR: thank you for starting this discussion, it was required as it's not
> >> an easy decision to take as there is no realistic perfect solution,
> >
> > Our (team-wide) pleasure. This is something we have been digging since
> > 2015.
> >
> >> but I
> >> believe you took the wrong decision. Please consider deferring the
> >> decision to the technical committe by seeking his advice (point 6.1.3
> >> of the constitution
> >> https://www.debian.org/devel/constitution.en.html#item-6).
> >
> > Will "kind of" do. Read below.
> >
> >
> >> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> >> > It seems now clear that the general consensus seems to expect:
> >> > = Qt available for both Desktop and ES OpenGL flavours
> >> > = If no change is possible, keep arm64 with Desktop OpenGL support
> >>
> >> I'm not pleased with how this discussion was handled. First of all,
> >> you did not leave enough time for all stakeholders to participate in
> >> the discussion (started on November 22th, closed November 25th, 3 days,
> >> that's not a reasonable timeframe in particular when 2 of the 3 days
> >> were in the week-end).
> >
> > My most sincere apologies if our timeframe do not fit yours.
> >
> > Now, wrt the decision: clearly the situation is very complex, involving many
> >
> > different kinds of arm64 devices, drivers, libraries et all. People involved
> >
> > have different opinions. We so far have been the proxy between them, be it
> > on
> > bugs, IRC or whatever other channels our users have to contact us. We prefer
> >
> > not to be this proxy anymore (again, read below).
> >
> > Besides we (Qt's team) have just learned that the Desktop/ES support is not
> >
> > tied to the hardware but to the driver. That's a particularly interesting
> > point.
> >
> > So:
> >
> > To quote my original mail, the "Qt available for both Desktop and ES OpenGL
> >
> > flavours" point remains unchanged: if someone wants to make it happen [s]he
> >
> > must join the team and support it from the inside. Remember there are little
> >
> > chances for this to happen in time for Buster.
> >
> > For the second point, "If no change is possible, keep arm64 with Desktop
> > OpenGL support", we have this position: we will keep the status quo,
> > deferring
> > users who want GLES support to Ubuntu.
> >
> > *But* we are open to change this for any arch (read it: support either one
> > or
> > the other technology) as long as the decision is taken by the technical
> > committee. As I wrote before, we will keep the status quo, so if anyone is
> > interested in any change feel free to contact the TC.
> >
> > Regards, Lisandro.
> >
> > --
> > Lisandro Damián Nicanor Pérez Meyer
> > http://perezmeyer.com.ar/
> > http://perezmeyer.blogspot.com/
> >
> 
> 
> -- 
> -
> No, I won't  call it "climate change", do you have a "reality problem"? - 
> AB1JX
> Cities are cages built to contain excess people and keep them from
> cluttering up nature.
> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
> 

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


signature.asc
Description: PGP signature