[Mesa-dev] Question about handling RGBA/BGRA in etnaviv driver

[Erik Faye-Lund]

On Fri, Feb 3, 2017 at 11:06 AM, Wladimir <laanwj at gmail.com> wrote:
> Yes, but it seems suboptimal, incurring overhead on every rendered pixel.

Why would this incur overhead? Can't the etnaviv-hardware perform
swizzles for free? I'd assume you could just remap writes to
gl_FragColor-compoents...

>
> 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?
>
> Wladimir
>
> On Feb 3, 2017 11:00, "Christian Gmeiner" <christian.gmeiner at gmail.com>
> wrote:
>>
>> Hi,
>>
>> 2017-02-03 10:56 GMT+01:00 Wladimir J. van der Laan <laanwj at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>