[Mesa-dev] [RFC PATCH] mesa/st: don't prematurely optimize for render targets when on virgl

[Ilia Mirkin]

On Tue, Jul 10, 2018 at 10:59 AM, Gert Wollny <gert.wollny at collabora.com> wrote:
> Am Dienstag, den 10.07.2018, 10:47 -0400 schrieb Ilia Mirkin:
>> In practice, no one allocates GL_RGB textures. Only RGBX/RGBA. In
>> part due to this issue, an in part due to the hardware not being able
>> to support rendering to such textures (and usually not texturing
>> either).
> I see. Well, I was close to solve this problem by exactly doing that,
> but on the way I lost ARB_tbo_rgb32. Anyway, if I understand you
> correctly, then this should be solvable on the driver level.
>
>> ARB_tbo_rgb32 is part of GLES 3.1 as I recall, but this only has to
>> do with buffer objects, so not renderable.
> I actually dind't find it at all in the spec. only that all the GL_RGB
> textures don't need to be renderable in general.
>
>>
>> Separately, glCopyImageSubData has to work between compatible
>> internal formats, irrespective of what happens under the hood. If
>> i965 can't copy from a GL_RGB32F texture to a GL_RGB32I texture,
>> that's a i965 bug.
> Intel is doing just fine, it's gallium that has a problem here. I think
> it assumes that the checks for compatibility done on the mesa side are
> sufficient, and doesn't check whether the actual internal formats are
> compatible (with the exception of an assertion though). I'm just not
> sure whether the copy fallback path implemented there is also useful
> for this case.

Right ... that logic is a bit finicky. It assumes that the driver
presents a logical group of formats.

Here's how every real driver handles it:

If it's a texture, don't support rgb-only formats (except r11g11b10f and so on).

In the is_format_supported check, there are explicit tests for target
== PIPE_BUFFER in order to allow the tbo_rgb32 case.

Cheers,

  -ilia