Re: Upcoming Qt switch to OpenGL ES on arm64
Hi,
On 26/11/18 8:58 pm, Riku Voipio wrote:
> On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
>> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
>
>> The real issue here is that *many* arm64 boards currently do not support
>> Desktop OpenGL, but do support GLES.
> The boards may or may not support Desktop GL. As far as debian is
> concerned, they remain headless devices until they have free drivers.
>
> See, most of the propiertary GLES drivers are craptastic and don't work
> with Debians kernel. Even ff you manage to dance the right kernel, device
> tree and userspace combo, you may still not get the desktop enviroment
> up. And nobody is going to fix the bugs you encounter.
>
> Debian does support Qualcomm based boards with freedreno driver, and
> work is progressing with etnaviv for Vivante. Both based on Mesa and
> support both OpenGL and GLES. With the MALI reverse engineering active
> again, it would seem rather short-sighted and counterproductive to
> put lots of energy in supporting the propiertary drivers.
>
I agree, hence let's do the switch and focus on developing free drivers.
I fully echo your sentiment and propose a practical approach to give the
best possible support to the developers whilst also providing something
real to the user. In awe of the efforts that have already gone into
these development activities - right now we don't have the drivers, thus
we lack both OpenGL & OpenGL ES support for the majority of the arm64
platforms and considering the hard work and time it has taken already, I
doubt that we will have stable full OpenGL support anytime soon.
Making the switch means that we can give the hardware the proprietary
support available right now, develop GLES support, roll it out, extend
it to full OpenGL support and once that is reasonably mature switch back
to desktop.
>> Also applications using GLU[T] or glew will not be able to compile anymore on
>> arm64. GLU[T] has not been ported to GLES, glew somehow differs in a type
>> definition.
> I have an Synquacer box with nvidia card running Lxqt desktop, running
> fine most tasks. While none of the apps I run on it seem to be of the
> Qt + GLU/glew combo, it would be unfortunate if I ever need to use them.
>
> Riku
>
Many thanks
Reply to: