Upcoming Qt switch to OpenGL ES on arm64

Fri Nov 23 00:17:29 GMT 2018

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-kde-talk/attachments/20181122/90f7d1e1/attachment.sig>