When requesting a texture of the internal format GL_RGB32F Gallium will
try to allocate a renderable texture and returns RGBA32F or RGBX32F, but
when one requests GL_RGB32I or GL_RGB32UI the according 3-component
texture will be returned. This leads to problems later, when one wants
to use glCopyImageSubData to copy data between these textures that should
be compatible, but given the way virgl and Gallium handle this the latter
fails with an assertion, because the per-texel bit size is different.
By allowing the GL_RGB32* only for texture buffers these problems are avoided
without losing the ARB_tbo_rgb32 extension (thanks Ilia Mirkin).
Signed-off-by: Gert Wollny <gert.wol...@collabora.com>
---
src/gallium/drivers/virgl/virgl_screen.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers/virgl/virgl_screen.c
b/src/gallium/drivers/virgl/virgl_screen.c
index 2a340b004f..1dbd88dee8 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -496,6 +496,13 @@ virgl_is_format_supported( struct pipe_screen *screen,
return virgl_is_vertex_format_supported(screen, format);
}
+ /* Allow 3-comp 32 bit texturs only for TBOs (needed for ARB_tbo_rgb32) */
+ if ((format == PIPE_FORMAT_R32G32B32_FLOAT ||
+ format == PIPE_FORMAT_R32G32B32_SINT ||
+ format == PIPE_FORMAT_R32G32B32_UINT) &&
+ target != PIPE_BUFFER)
+ return FALSE;
+
if (bind & PIPE_BIND_RENDER_TARGET) {
if (format_desc->colorspace == UTIL_FORMAT_COLORSPACE_ZS)
return FALSE;
--
2.17.1
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
