On Tue, Jul 10, 2018 at 10:59 AM, Gert Wollny <gert.wol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev