[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upcoming Qt switch to OpenGL ES on arm64

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

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

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