[virglrenderer-devel] regarding ARGB_copy_image and 3 component textures

[Dave Airlie]

On 6 July 2018 at 01:53, Gert Wollny <gert.wollny at collabora.com> wrote:
> Dear all,
>
> I'm running into a dead end trying to get three componet textures to
> behave with the copy_image tests (both piglit and dEQP-GLES31).
>
> The problems that I initially encountered were that on an Intel host a
> RBG32F texture would be represented by 128 bit per texel (as RGBA32F)
> in a way visible to the host and the RGB32UI and RGB32I textures were
> still in 96 bits. As a result an assertion in gallium copy_image fired,
> because only textures with the same texel bit count can be copied.
>
> In a similar way, on the R600 host copying between sRGB and RGB failed,
> because the latter was represented as a four component texture, but the
> sRGB texture not, and virglrenderer directed the blit to use
> framebuffer blits which failed because of the gamma correction
> involved.
>
> Given that two different hosts showed different problems I thought that
> solving this is probably best done by forcing to use four component
> textures with a one-swizzle in the alpha channel. This actually seemed
> to work out well, but now I had to realize that this also removed
> GL_ARB_texture_buffer_object_rgb32 from the list of supported
> extensions.
>
> I still think that the four-component approach is a possible solution,
> but I'm not sure about how to keep the extension. Any ideas?

I'm going to have expend some quality time on this 3 component
is always a pita, and I think there are some things about treating
them different when texture buffer objects are in use vs when they aren't,
as in you can store them in 4 components normally, except in some TBO
cases,

We definitely don't want to lost tbo_rgb32 from the supported extensions
since that is GL4.0.

Dave.