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