Upcoming Qt switch to OpenGL ES on arm64

classic Classic list List threaded Threaded
110 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Upcoming Qt switch to OpenGL ES on arm64

Dmitry Shachnev-3
Hi all!

The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
support. At the moment we are building it with OpenGL ES on armel and armhf,
and with desktop OpenGL on all other architectures.

However we have received a request [1] from two different persons to add arm64
to the list of architectures where OpenGL ES is used.

We want your feedback! If you are using an arm64 device or board with Qt,
please let us know your opinion about this change, by replying to this mail
or to [1], and describe your use case.

So far we are going to make this change starting with the Qt 5.11.3 packages.
In case you already want to test it, the updated qtbase package is available
in experimental [2]. However the reverse dependencies are not yet rebuilt.

This change will affect packages using Qt Gui [3], Qt Widgets [4], Qt Quick
and some other modules. It will not affect packages using the deprecated Qt
OpenGL module because it loads the OpenGL library at runtime.

The best way to check whether some package needs changes is checking Ubuntu
[5], which has been building Qt with OpenGL ES on arm64 since version 16.10
(yakkety) [6].

We will send a new mail with DD-list of packages that we detect to be affected
a bit later.

There are some packages that are not compatible with OpenGL ES. For example,
packages using libglu and Qt simultaneously will most likely have to drop
their arm64 binaries (like they already have no armel or arm64 binaries).
An example of such package is qwtplot3d.

Also note that as this change breaks ABI on arm64, we are renaming libqt5gui5
to libqt5gui5a, which will need binNMUs of all reverse dependencies. The list
of all such dependencies is available here [7]. This will happen together with
the Qt 5.11.3 transition.

Please Cc me or pkg-kde-talk on reply.

[1]: https://bugs.debian.org/881333
[2]: https://tracker.debian.org/news/1004843/
[3]: https://doc.qt.io/qt-5/qtgui-index.html#opengl-and-opengl-es-integration
[4]: https://doc.qt.io/qt-5/qopenglwidget.html
[5]: https://launchpad.net/ubuntu/+source/${SOURCE_PACKAGE_NAME},
     or the “ubuntu patches” link in the right panel of tracker.debian.org
[6]: https://salsa.debian.org/qt-kde-team/qt/qtbase/commit/197063f08928ac9c
[7]: https://perezmeyer.com.ar/ben/qtbase.html

--
Dmitry Shachnev

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

Re: Upcoming Qt switch to OpenGL ES on arm64

Marcin Juszkiewicz-4
W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:

> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
> support. At the moment we are building it with OpenGL ES on armel and armhf,
> and with desktop OpenGL on all other architectures.
>
> However we have received a request [1] from two different persons to add arm64
> to the list of architectures where OpenGL ES is used.
>
> We want your feedback! If you are using an arm64 device or board with Qt,
> please let us know your opinion about this change, by replying to this mail
> or to [1], and describe your use case.

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

>From what I see the problem is with Qt not being able to be built with
support for both OpenGL and OpenGLES ;(

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

John Paul Adrian Glaubitz


> On Nov 22, 2018, at 10:30 PM, Marcin Juszkiewicz <[hidden email]> wrote:
>
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
>
>> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
>> support. At the moment we are building it with OpenGL ES on armel and armhf,
>> and with desktop OpenGL on all other architectures.
>>
>> However we have received a request [1] from two different persons to add arm64
>> to the list of architectures where OpenGL ES is used.
>>
>> We want your feedback! If you are using an arm64 device or board with Qt,
>> please let us know your opinion about this change, by replying to this mail
>> or to [1], and describe your use case.
>
> 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).

Correct. After this switch, Qt on arm64 will be forced into embedded mode when it comes to graphics.

Not sure whether it’s the right decision to be made. Might be an idea to ask more users on their opinions on this issue.

Granted, I don’t really know what the real world distribution of embedded and desktop/server/laptop devices of arm64 is.  But I could imagine that there will be more arm64 devices in the future which are desktops, servers or laptops.

Adrian
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Julien Cristau-6
In reply to this post by Marcin Juszkiewicz-4
On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:

> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
>
>> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
>> support. At the moment we are building it with OpenGL ES on armel and armhf,
>> and with desktop OpenGL on all other architectures.
>>
>> However we have received a request [1] from two different persons to add arm64
>> to the list of architectures where OpenGL ES is used.
>>
>> We want your feedback! If you are using an arm64 device or board with Qt,
>> please let us know your opinion about this change, by replying to this mail
>> or to [1], and describe your use case.
>
> 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).
>
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? :)

Cheers,
Julien

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Lisandro Damián Nicanor Pérez Meyer-2
El jueves, 22 de noviembre de 2018 19:05:27 -03 Julien Cristau escribió:

> On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> >> The Qt framework can be built either with “desktop” OpenGL, or with
> >> OpenGL ES support. At the moment we are building it with OpenGL ES on
> >> armel and armhf, and with desktop OpenGL on all other architectures.
> >>
> >> However we have received a request [1] from two different persons to add
> >> arm64 to the list of architectures where OpenGL ES is used.
> >>
> >> We want your feedback! If you are using an arm64 device or board with Qt,
> >> please let us know your opinion about this change, by replying to this
> >> mail
> >> or to [1], and describe your use case.
> >
> > 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).
>
> 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? :)
That would mean that anything using Qt + [GLU[T] glew] will have to get
removed from the archive.

Now let's suppose for a minute that the above could be solvable: it would be
good to know whether this is in fact a possible solution.

In this case the question would be: do the major part of the video cards out
there support GLES?


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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

Lisandro Damián Nicanor Pérez Meyer-2
In reply to this post by Dmitry Shachnev-3
El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:
> Hi all!
>
> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL
> ES support. At the moment we are building it with OpenGL ES on armel and
> armhf, and with desktop OpenGL on all other architectures.

Maybe we missed to properly explain the main point of this change: currently
most arm64 boards are using software rasterization because their video cards
do not support Desktop OpenGL. If we switch to GLES then most amr64 boards
will be able to render using their video hardware, thus greatly improving
speed to the point of being actually usable for some stuff.

I imagine (but would *love* hard data) that any PCI video card added to an
arm64 machine will probably also support GLES, so they will still have use.

But one thing is for sure: it's not a decision in which everyone wins, so we
are trying to make a decision on which *most* of our users wins.  


--
When the winds of change are blowing, some people are building shelters, and
others are building windmills.
  Old Chinese Proverb

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

Gene Heskett-4
In reply to this post by Lisandro Damián Nicanor Pérez Meyer-2
On Thursday 22 November 2018 17:27:35 Lisandro Damián Nicanor Pérez Meyer
wrote:

> El jueves, 22 de noviembre de 2018 19:05:27 -03 Julien Cristau
escribió:

> > On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> > > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> > >> The Qt framework can be built either with “desktop” OpenGL, or
> > >> with OpenGL ES support. At the moment we are building it with
> > >> OpenGL ES on armel and armhf, and with desktop OpenGL on all
> > >> other architectures.
> > >>
> > >> However we have received a request [1] from two different persons
> > >> to add arm64 to the list of architectures where OpenGL ES is
> > >> used.
> > >>
> > >> We want your feedback! If you are using an arm64 device or board
> > >> with Qt, please let us know your opinion about this change, by
> > >> replying to this mail
> > >> or to [1], and describe your use case.
> > >
> > > 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).
> >
> > 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? :)
>
> That would mean that anything using Qt + [GLU[T] glew] will have to
> get removed from the archive.
>
> Now let's suppose for a minute that the above could be solvable: it
> would be good to know whether this is in fact a possible solution.
>
> In this case the question would be: do the major part of the video
> cards out there support GLES?

This reply is going to indict far more than just the video you are
referring to although it is included.

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?  It has great hardware specs, 4 gigs of
system ram, a 4 core arm64 cpu running faster than most of the sbc's,
but no support for installing either a realtime kernel so it can run
machine controller apps, which use the spi to talk to controller cards
with 3x the pcb real estate than the rock64 itself. Its spi is glacial
compared to what can be done on a far less well endowed r-pi-3b, which
can write to the controller card at 42 megabaud, and read its response
at 25 megabaud, and so far it seems that broadcom patents (from what
I've read) are preventing any linux use of the mali video chips it has,
leaving it with framebuffer only video if the install is linux. You
don't run real world app's with a 6 frames a second video.

All but one of the jessie/stretch system's available for the arm**'s
today, have the first user=1000 hard coded, only the armbian stretch
allows the first user to be created on first boot.

You would be doing the developer world for such sbc's a lot more good,
making it run well on a $44 sbc. What I'm reading here seems only to
apply to systems in the thousand dollar and up category.

My $0.02.

--
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 <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Gene Heskett-4
In reply to this post by Lisandro Damián Nicanor Pérez Meyer-2
On Thursday 22 November 2018 17:33:50 Lisandro Damián Nicanor Pérez Meyer
wrote:

> El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev
escribió:

> > Hi all!
> >
> > The Qt framework can be built either with “desktop” OpenGL, or with
> > OpenGL ES support. At the moment we are building it with OpenGL ES
> > on armel and armhf, and with desktop OpenGL on all other
> > architectures.
>
> Maybe we missed to properly explain the main point of this change:
> currently most arm64 boards are using software rasterization because
> their video cards do not support Desktop OpenGL. If we switch to GLES
> then most amr64 boards will be able to render using their video
> hardware, thus greatly improving speed to the point of being actually
> usable for some stuff.
>
> I imagine (but would *love* hard data) that any PCI video card added
> to an arm64 machine will probably also support GLES, so they will
> still have use.
>
> But one thing is for sure: it's not a decision in which everyone wins,
> so we are trying to make a decision on which *most* of our users wins.

The huge majority of the armhf/arm64 cards being put to work today do not
have a pci slot and never will, yet there are 100 of these tiny sbc's
out here doing real work that will never do it thru a pci or pci-e
connector.

Today, on arm stuff, that interface is SPI, and it runs at speeds up to
50 megabaud on the r-pi-3b. Give us a kernel installer that Just Works
using a kernel we've downloaded the src for and built right on these
teeny boards, and give us a 50 megabaud SPI driver, support the mali
video chips these things come with, and a huge bunch of these little
cards will be off to the races.

--
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 <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Lisandro Damián Nicanor Pérez Meyer-2
In reply to this post by Lisandro Damián Nicanor Pérez Meyer-2
Hi! Please let me reply first to your last part:

> Is there any possible way to support *BOTH* OpenGL / OpenGLES?  Mutually
> exclusive from an install POV, but give the end user the choice which to
> install?  Why should we have one Architecture forced down a path
> different to another architecture?

No, I'm afraid there is no way to do that. We did consider it many times, but
is definitely too much work to hack on.

So we need to force an architecture (actually, all of them!) to either one or
the other.


El jueves, 22 de noviembre de 2018 20:04:33 -03 Andy Simpkins escribió:

> On 22/11/18 22:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> > El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:
> >> Hi all!
> >>
> >> The Qt framework can be built either with “desktop” OpenGL, or with
> >> OpenGL
> >> ES support. At the moment we are building it with OpenGL ES on armel and
> >> armhf, and with desktop OpenGL on all other architectures
> >
> > Maybe we missed to properly explain the main point of this change:
> > currently most arm64 boards are using software rasterization because
> > their video cards do not support Desktop OpenGL.
>
> I am not sure that is correct.  I certainly don't agree...
>
> There is no special case here.  If you have a video card in your ARM64
> PC then it is likely the same video card that you have for an AMD64 PC -
> i.e. it is an off the shelf PCIe card.
>
> Now it is correct that there is a large number of ARM64 based SoC
> solutions out there with an embedded GPU - these are aimed mainly at the
> mobile market (but as the computational power in these SoCs increases we
> are already seeing that is enough for a lot of peoples 'PC' needs)
>
> I guess what I am trying to say here is the GPU architecture is NOT tied
> to the CPU architecture.
- GPU architecture is not tied to the arch: right.
- 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.

> If we switch to GLES then most amr64 boards
>
> > will be able to render using their video hardware, thus greatly improving
> > speed to the point of being actually usable for some stuff.
> >
> > I imagine (but would *love* hard data) that any PCI video card added to an
> > arm64 machine will probably also support GLES, so they will still have
> > use.
>
> So <sarcasm>
> any PCI video card added to s/amr64/AMD64 machine will probably also
> support GLES, so they will still have use.
> OK that is true - lets enact this across ALL architectures, but I
> suspect that there may be a bit of pushback from the AMD64 heavy graphic
> users...
> </sarcasm>
No need to use sarcasm. Yes, it's a matter of choice. No one noted yet that
all archs except armel and armhf have Desktop support and not GLES. And this
is because, so far and to the best of our knowledge, that has been the right
thing to do.

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


--
Contrary to popular belief, Unix is user friendly. It just happens to be
very selective about who it decides to make friends with.
  Unknown - http://www.linfo.org/q_unix.html

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

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

Re: Upcoming Qt switch to OpenGL ES on arm64

Dmitry Eremin-Solenikov
Hello,
пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer
<[hidden email]>:

>
> Hi! Please let me reply first to your last part:
>
> > Is there any possible way to support *BOTH* OpenGL / OpenGLES?  Mutually
> > exclusive from an install POV, but give the end user the choice which to
> > install?  Why should we have one Architecture forced down a path
> > different to another architecture?
>
> No, I'm afraid there is no way to do that. We did consider it many times, but
> is definitely too much work to hack on.
>
> So we need to force an architecture (actually, all of them!) to either one or
> the other.

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

> El jueves, 22 de noviembre de 2018 20:04:33 -03 Andy Simpkins escribió:
> > On 22/11/18 22:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:
> > >> Hi all!
> > >>
> > >> The Qt framework can be built either with “desktop” OpenGL, or with
> > >> OpenGL
> > >> ES support. At the moment we are building it with OpenGL ES on armel and
> > >> armhf, and with desktop OpenGL on all other architectures
> > >
> > > Maybe we missed to properly explain the main point of this change:
> > > currently most arm64 boards are using software rasterization because
> > > their video cards do not support Desktop OpenGL.
> >
> > I am not sure that is correct.  I certainly don't agree...
> >
> > There is no special case here.  If you have a video card in your ARM64
> > PC then it is likely the same video card that you have for an AMD64 PC -
> > i.e. it is an off the shelf PCIe card.
> >
> > Now it is correct that there is a large number of ARM64 based SoC
> > solutions out there with an embedded GPU - these are aimed mainly at the
> > mobile market (but as the computational power in these SoCs increases we
> > are already seeing that is enough for a lot of peoples 'PC' needs)
> >
> > I guess what I am trying to say here is the GPU architecture is NOT tied
> > to the CPU architecture.
>
> - GPU architecture is not tied to the arch: right.
> - 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.

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.

--
With best wishes
Dmitry

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Gene Heskett-4
In reply to this post by Lisandro Damián Nicanor Pérez Meyer-2
On Thursday 22 November 2018 19:17:29 Lisandro Damián Nicanor Pérez Meyer
wrote:

> Hi! Please let me reply first to your last part:
> > Is there any possible way to support *BOTH* OpenGL / OpenGLES?
> > Mutually exclusive from an install POV, but give the end user the
> > choice which to install?  Why should we have one Architecture forced
> > down a path different to another architecture?
>
> No, I'm afraid there is no way to do that. We did consider it many
> times, but is definitely too much work to hack on.
>
> So we need to force an architecture (actually, all of them!) to either
> one or the other.
>
> El jueves, 22 de noviembre de 2018 20:04:33 -03 Andy Simpkins escribió:
> > On 22/11/18 22:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev
escribió:

> > >> Hi all!
> > >>
> > >> The Qt framework can be built either with “desktop” OpenGL, or
> > >> with OpenGL
> > >> ES support. At the moment we are building it with OpenGL ES on
> > >> armel and armhf, and with desktop OpenGL on all other
> > >> architectures
> > >
> > > Maybe we missed to properly explain the main point of this change:
> > > currently most arm64 boards are using software rasterization
> > > because their video cards do not support Desktop OpenGL.
> >
> > I am not sure that is correct.  I certainly don't agree...
> >
> > There is no special case here.  If you have a video card in your
> > ARM64 PC then it is likely the same video card that you have for an
> > AMD64 PC - i.e. it is an off the shelf PCIe card.
> >
> > Now it is correct that there is a large number of ARM64 based SoC
> > solutions out there with an embedded GPU - these are aimed mainly at
> > the mobile market (but as the computational power in these SoCs
> > increases we are already seeing that is enough for a lot of peoples
> > 'PC' needs)
> >
> > I guess what I am trying to say here is the GPU architecture is NOT
> > tied to the CPU architecture.
>
> - GPU architecture is not tied to the arch: right.
> - 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.
>
> > If we switch to GLES then most amr64 boards
> >
> > > will be able to render using their video hardware, thus greatly
> > > improving speed to the point of being actually usable for some
> > > stuff.
> > >
> > > I imagine (but would *love* hard data) that any PCI video card
> > > added to an arm64 machine will probably also support GLES, so they
> > > will still have use.
> >
> > So <sarcasm>
> > any PCI video card added to s/amr64/AMD64 machine will probably also
> > support GLES, so they will still have use.
> > OK that is true - lets enact this across ALL architectures, but I
> > suspect that there may be a bit of pushback from the AMD64 heavy
> > graphic users...
> > </sarcasm>
>
> No need to use sarcasm. Yes, it's a matter of choice. No one noted yet
> that all archs except armel and armhf have Desktop support and not
> GLES. And this is because, so far and to the best of our knowledge,
> that has been the right thing to do.
>
> So: what's the best outcome for our *current* users? Again, pick only
> one.

And that is something you probably won't have the power to do, because
the huge majority of these things are being designed by engineers
looking for the most bang for the buck, and coming up thru the schools
all run by M$ or Apple. Linux is simply not even on their radar.

But, what you do do, makes or breaks their success in doing things that
only linux can do best. Windows has no possibility of a realtime kernel,
linux does, has several choices depending on just how realtime you want.
Windows hasn't figured out what this thing called SPI is yet that I've
heard about.

One LinuxCNC driver has SPI figured out, and you can find it in the
LinuxCNC srcs as rpspi.c, but the professor that wrote it, with me and
my pi 3b, driving a 70 yo Sheldon 11x36 Lathe as lab rats to test it,
also wrote it so it only runs on an r-pi-3b. Fixing it to build and run
on another platform with a different, probably broadcom gpio driver
headers would be a very welcome addition to the arm toolbox as a whole,
but is beyond my well aged wet ram's ability at my age.

Now, I'll go play Al Capp from the comic strip and shaddup.

--
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 <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Steve McIntyre
In reply to this post by Dmitry Eremin-Solenikov
On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:

>Hello,
>пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer
><[hidden email]>:
>>
>> Hi! Please let me reply first to your last part:
>>
>> > Is there any possible way to support *BOTH* OpenGL / OpenGLES?  Mutually
>> > exclusive from an install POV, but give the end user the choice which to
>> > install?  Why should we have one Architecture forced down a path
>> > different to another architecture?
>>
>> No, I'm afraid there is no way to do that. We did consider it many times, but
>> is definitely too much work to hack on.
>>
>> So we need to force an architecture (actually, all of them!) to either one or
>> the other.
>
>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.

...

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

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.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect."
  -- Bruce Schneier

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

W. Martin Borgert
In reply to this post by John Paul Adrian Glaubitz
Quoting John Paul Adrian Glaubitz <[hidden email]>:
> Granted, I don’t really know what the real world distribution of  
> embedded and desktop/server/laptop devices of arm64 is.  But I could  
> imagine that there will be more arm64 devices in the future which  
> are desktops, servers or laptops.

There is e.g. this project from Berlin:

https://mntmn.com/reform/

It says:

  * Vivante GC3000 GPU
    Fully open source drivers in the Linux kernel (etnaviv)
    and OpenGL (mesa)

I will buy one as soon as available.

There is also Novena:

https://www.crowdsupply.com/sutajio-kosagi/novena

No idea what they use for graphics.

Cheers

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Dmitry Shachnev-3
In reply to this post by Julien Cristau-6
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.

[1]: https://code.qt.io/cgit/qt/qtbase.git/tree/config_help.txt#n271

--
Dmitry Shachnev

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

Re: Upcoming Qt switch to OpenGL ES on arm64

Julien Cristau-6
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

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Dmitry Shachnev-3
In reply to this post by Gene Heskett-4
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Dmitry Shachnev-3
In reply to this post by Lisandro Damián Nicanor Pérez Meyer-2
On Fri, Nov 23, 2018 at 09:34:44AM +0000, 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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Marcin Juszkiewicz-4
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.

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Dmitry Shachnev-3
In reply to this post by Julien Cristau-6
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming Qt switch to OpenGL ES on arm64

Dmitry Shachnev-3
In reply to this post by Marcin Juszkiewicz-4
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 (849 bytes) Download Attachment
1234 ... 6