Question about handling RGBA/BGRA in etnaviv driver

[Christian Gmeiner]

Hi,

2017-02-03 10:56 GMT+01:00 Wladimir J. van der Laan <laanwj at gmail.com>:
> Hello,
>
> With the Etnaviv driver we're running into an issue: The GPU can only render *to*
> BGRA formats. It can however render *from* BGRA as well as RGBA textures.
>
> I know that the OpenGL ES standard allows drivers to choose what order is most
> appropriate when being asked for "GL_RGBA" textures. So back when etnaviv supported
> only BGRA, Mesa automatically picked that and everything was okay.
>
> However a recent patch added support for RGBA formats in etnaviv_format.c.
>
> Now, Mesa creates a real GL_RGBA texture when this is requested. This is all
> and well for rendering, however for anything using FBO to render to textures
> this is a problem.
>
> Qt, for example, is assuming it can attach the GL_RGBA texture to a FBO. This
> fails now that GL_RGBA textures are really GL_RGBA, and it doesn't handle that
> error to fall back to something else so rendering issues ensue.
>
> I'm not sure how to handle this:
>
> - The quick fix would be to revert the RGBA formats patch, but the hardware
>   supports rendering *from* RGBA textures fine so this would be throwing away a
>   feature.
>
> - Another way would be to try to fix Qt to cope with this, and try e.g. GL_BGRA_EXT
>   when it wants to render to a texture. Burdening the client code with this seems
>   unintuitive to me.
>
> - Another hack would be to implement shader variants, and swap R/B in the pixel
>   shader to emulate rendering to RGBA.
>

In my opinion shader variants are the way to go - almost every driver
make use of them to
'fix' such issues.

greets
--
Christian Gmeiner, MSc

https://www.youtube.com/user/AloryOFFICIAL
https://soundcloud.com/christian-gmeiner