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.
Neither seems great. Does anyone have suggestions, do any of the other (gallium) drivers have this problem?
Regards, Wladimir
Hi,
2017-02-03 10:56 GMT+01:00 Wladimir J. van der Laan laanwj@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
Sorry for getting the list wrong again. Please reply to mesa-dev not dri-dev .
---------- Forwarded message ---------- From: "Wladimir J. van der Laan" laanwj@gmail.com Date: Feb 3, 2017 10:56 Subject: Question about handling RGBA/BGRA in etnaviv driver To: dri-devel@lists.freedesktop.org, etnaviv@lists.freedesktop.org Cc: "Chris Healy" cphealy@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.
Neither seems great. Does anyone have suggestions, do any of the other (gallium) drivers have this problem?
Regards, Wladimir
dri-devel@lists.freedesktop.org
-
Christian Gmeiner -
Wladimir -
Wladimir J. van der Laan