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

[Wladimir J. van der Laan]

> > 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.

I implemented this today, but unfortunately it's not working.

MESA doesn't like the format of the gallium texture changing under it, as it
tracks its own formats. This results in assertion errors later on when it tries
to copy data to the texture (as it assumes it can just use copy_region).

It would be possible to add a "fake" resource res->rtt for rendering to
(similar to how res->texture is used for rendering *from*), then copy and
convert as needed, but I don't think the added complexity is worth it. It would
no longer be a one-time overhead, every frame would be converted - for no good
reason but keep Mesa's higher-level texture handling happy.

If we can't come up with a better solution to this I'd say the most
straightforward solution to that would be to revert "etnaviv: add RGBX/RGBA
pixel formats".

I guess in a way this problem is at a higher level, maybe it should be solved
at the Mesa / GL ES level - applications using OpenGL ES API expect an
abstraction "GL_RGBA" which does not necessarily need to use RGBA layout in
memory.

(On the other hand for desktop GL the internal format is the internal format and
it may be expected behavior that a GPU that doesn't support rendering to
GL_RGBA rejects FBO's set up that way?)

Wladimir