Upcoming Qt switch to OpenGL ES on arm64

classic Classic list List threaded Threaded
109 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
In reply to this post by Marcin Juszkiewicz-4
El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:

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

I *think* that most video cards support both GLES and Desktop OpenGL, but feel
free to point me wrong.

Also I understand that if your video card does not supports GLES then
software-based rendering might happen.

The real issue here is that *many* arm64 boards currently do not support
Desktop OpenGL, but do support GLES.

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.

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

That would be ideal, but yes, it's currently a build-time selection.

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

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 John Paul Adrian Glaubitz
El jueves, 22 de noviembre de 2018 18:51:20 -03 John Paul Adrian Glaubitz
escribió:

> > 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.
s/graphics/OpenGL specific classes.
 
> 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.

Well, it's not a new thing for us:

<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799113>
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881333>

I encourage anyone who wants to know more details to dig into that bug. As you
can see the first one was filled by myself on 2015...


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

...and that was exactly what we have been doing since 2015. Now in #881333
Raphael pointed for new data and the need for GLES as one thing is having
software-based rendering and quite another having hardware-accelerated
rendering.


--
Only wimps use tape backup: real men just upload their important stuff on
ftp, and let the rest of the world mirror it ;)
  Linus Benedict Torvalds.

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

Andy Simpkins-5
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.


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>

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

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?

/Andy

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

Andy Simpkins-3
In reply to this post by Lisandro Damián Nicanor Pérez Meyer-2

On 23/11/2018 00:17, 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 this is a large parcel of work that the team doesn't want to do, but
it is possible.

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

>
> 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.
I have quite a lot of ARM boards (for the record I am neither an ARM or
Lenaro
employee, but I do design hardware using ARM cores).

I have 2 arm64 motherboards - both have PCIe slots and no GPU built into
the SoC
these are Both MiniITX form factor boards and are drop-in replacements
for amd64 based
systems.  They both have multiple SATA interfaces, DIMM slots etc etc.

I have several armhf boards - these all have OpenGLES supporting GPUs on
the SoC.
Only one of them has a (single) SATA interface, none of them have DIMM
slots (instead
having between 512MB and 2GB LPDDR soldered to the board)  None of these
are desktop
PC replacements - they are embedded systems (think tablet / mobile /
dedicated task
systems).

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 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.
>
You can't pick one that is the real issue.  The class of machine is the
closest
you will get for a dividing line - mobile devices are largely going to
be OGLES,
whilst desktops will have the same GPUs found in amd64 based machines. 
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

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 Lisandro Damián Nicanor Pérez Meyer-2
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 Andy Simpkins-3
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
1234 ... 6