Re: Upcoming Qt switch to OpenGL ES on arm64
On Thursday 22 November 2018 17:27:35 Lisandro Damián Nicanor Pérez Meyer
wrote:
> El jueves, 22 de noviembre de 2018 19:05:27 -03 Julien Cristau
escribió:
> > On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> > > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> > >> 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.
> > >>
> > >> However we have received a request [1] from two different persons
> > >> to add arm64 to the list of architectures where OpenGL ES is
> > >> used.
> > >>
> > >> We want your feedback! If you are using an arm64 device or board
> > >> with Qt, please let us know your opinion about this change, by
> > >> replying to this mail
> > >> or to [1], and describe your use case.
> > >
> > > Does it mean that arm64 box with PCI Express graphics card will be
> > > not able to use Qt based software? I can put Radeon or NVidia card
> > > into my box and use it as a normal OpenGL accelerated desktop (did
> > > that already few years ago).
> >
> > At least mesa drivers can be used for desktop GL or GLESv2 just
> > fine, AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
> > architectures, to stop the special-casing madness, instead of making
> > it spread? :)
>
> That would mean that anything using Qt + [GLU[T] glew] will have to
> get removed from the archive.
>
> Now let's suppose for a minute that the above could be solvable: it
> would be good to know whether this is in fact a possible solution.
>
> In this case the question would be: do the major part of the video
> cards out there support GLES?
This reply is going to indict far more than just the video you are
referring to although it is included.
I think a better question would be: Does it improve, or disable, decent
video support for the dozens of arm64 cards in the r-pi format, such as
the arm64 based $44 rock64? It has great hardware specs, 4 gigs of
system ram, a 4 core arm64 cpu running faster than most of the sbc's,
but no support for installing either a realtime kernel so it can run
machine controller apps, which use the spi to talk to controller cards
with 3x the pcb real estate than the rock64 itself. Its spi is glacial
compared to what can be done on a far less well endowed r-pi-3b, which
can write to the controller card at 42 megabaud, and read its response
at 25 megabaud, and so far it seems that broadcom patents (from what
I've read) are preventing any linux use of the mali video chips it has,
leaving it with framebuffer only video if the install is linux. You
don't run real world app's with a 6 frames a second video.
All but one of the jessie/stretch system's available for the arm**'s
today, have the first user=1000 hard coded, only the armbian stretch
allows the first user to be created on first boot.
You would be doing the developer world for such sbc's a lot more good,
making it run well on a $44 sbc. What I'm reading here seems only to
apply to systems in the thousand dollar and up category.
My $0.02.
--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: