Hi Wladimir, 2017-02-03 11:06 GMT+01:00 Wladimir <laa...@gmail.com>: > Yes, but it seems suboptimal, incurring overhead on every rendered pixel. > > Another way that I just realized would be to convert a texture to BGRA the > first time it's rendered to. > > In contrast to the shader solution that has only a one-time overhead. Is > this a stupid idea for any reason? >
We are doing something similar to convert sampled textures to the correct tiling format for the multi-pipe GPUs. (sampler can read only from tiled formats but the multi-pipe GPU can only render to multi-tiled or super-tiled resources). Have a look where etna_copy_resource(..) gets used. So this idea sound even better to me. > Wladimir > > On Feb 3, 2017 11:00, "Christian Gmeiner" <christian.gmei...@gmail.com> > wrote: >> >> Hi, >> >> 2017-02-03 10:56 GMT+01:00 Wladimir J. van der Laan <laa...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
