[Mesa-dev] [RFC PATCH] mesa/st: don't prematurely optimize for render targets when on virgl
imirkin at alum.mit.edu
Tue Jul 10 15:03:16 UTC 2018
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
> 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.
More information about the mesa-dev