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