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
