Re: Upcoming Qt switch to OpenGL ES on arm64
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 to: