<div dir="auto"><div>Sorry for getting the list wrong again. Please reply to mesa-dev not dri-dev .</div><div dir="auto"><br><div class="gmail_quote" dir="auto">---------- Forwarded message ----------<br>From: "Wladimir J. van der Laan" <<a href="mailto:laanwj@gmail.com">laanwj@gmail.com</a>><br>Date: Feb 3, 2017 10:56<br>Subject: Question about handling RGBA/BGRA in etnaviv driver<br>To:  <<a href="mailto:dri-devel@lists.freedesktop.org">dri-devel@lists.freedesktop.org</a>>,  <<a href="mailto:etnaviv@lists.freedesktop.org">etnaviv@lists.freedesktop.org</a>><br>Cc: "Chris Healy" <<a href="mailto:cphealy@gmail.com">cphealy@gmail.com</a>><br><br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
With the Etnaviv driver we're running into an issue: The GPU can only render *to*<br>
BGRA formats. It can however render *from* BGRA as well as RGBA textures.<br>
<br>
I know that the OpenGL ES standard allows drivers to choose what order is most<br>
appropriate when being asked for "GL_RGBA" textures. So back when etnaviv supported<br>
only BGRA, Mesa automatically picked that and everything was okay.<br>
<br>
However a recent patch added support for RGBA formats in etnaviv_format.c.<br>
<br>
Now, Mesa creates a real GL_RGBA texture when this is requested. This is all<br>
and well for rendering, however for anything using FBO to render to textures<br>
this is a problem.<br>
<br>
Qt, for example, is assuming it can attach the GL_RGBA texture to a FBO. This<br>
fails now that GL_RGBA textures are really GL_RGBA, and it doesn't handle that<br>
error to fall back to something else so rendering issues ensue.<br>
<br>
I'm not sure how to handle this:<br>
<br>
- The quick fix would be to revert the RGBA formats patch, but the hardware<br>
  supports rendering *from* RGBA textures fine so this would be throwing away a<br>
  feature.<br>
<br>
- Another way would be to try to fix Qt to cope with this, and try e.g. GL_BGRA_EXT<br>
  when it wants to render to a texture. Burdening the client code with this seems<br>
  unintuitive to me.<br>
<br>
- Another hack would be to implement shader variants, and swap R/B in the pixel<br>
  shader to emulate rendering to RGBA.<br>
<br>
Neither seems great. Does anyone have suggestions, do any of the other<br>
(gallium) drivers have this problem?<br>
<br>
Regards,<br>
Wladimir<br>
</blockquote></div><br></div></div>