<div dir="auto">Yes, but it seems suboptimal, incurring overhead on every rendered pixel.<div dir="auto"><br></div><div dir="auto">Another way that I just realized would be to convert a texture to BGRA the first time it's rendered to.<div dir="auto"><br></div><div dir="auto">In contrast to the shader solution that has only a one-time overhead. Is this a stupid idea for any reason?</div><div dir="auto"><br></div><div dir="auto">Wladimir</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Feb 3, 2017 11:00, "Christian Gmeiner" <<a href="mailto:christian.gmeiner@gmail.com">christian.gmeiner@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
2017-02-03 10:56 GMT+01:00 Wladimir J. van der Laan <<a href="mailto:laanwj@gmail.com">laanwj@gmail.com</a>>:<br>
> 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>
<br>
In my opinion shader variants are the way to go - almost every driver<br>
make use of them to<br>
'fix' such issues.<br>
<br>
greets<br>
--<br>
Christian Gmeiner, MSc<br>
<br>
<a href="https://www.youtube.com/user/AloryOFFICIAL" rel="noreferrer" target="_blank">https://www.youtube.com/user/<wbr>AloryOFFICIAL</a><br>
<a href="https://soundcloud.com/christian-gmeiner" rel="noreferrer" target="_blank">https://soundcloud.com/<wbr>christian-gmeiner</a><br>
</blockquote></div></div>