[Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver
l.stach at pengutronix.de
Fri Feb 3 10:12:00 UTC 2017
this is about the userspace component of the driver, so dri-devel isn't
the correct list for this question, you should instead CC the MESA dev
list, even if mostly the same people hang out on those lists.
Done that for you now.
Am Freitag, den 03.02.2017, 10:56 +0100 schrieb Wladimir J. van der
> 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
> - 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.
> Neither seems great. Does anyone have suggestions, do any of the other
> (gallium) drivers have this problem?
> etnaviv mailing list
> etnaviv at lists.freedesktop.org
More information about the mesa-dev