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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
