Web lists-archives.com

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