From: Roland Scheidegger <srol...@vmware.com>
It is rather unfortunate that we don't know if a texture is going to be used
as a rt later, and we lack the means to do something about a format chosen
which we can't render to directly, so disable this and always chose renderable
format for rgba8 textures.
This addresses an issue raised on (old) bug 51658 with gnome-shell, don't know
if that's still applicable but it might fix other things as well.
---
src/mesa/drivers/dri/radeon/radeon_texture.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_texture.c
b/src/mesa/drivers/dri/radeon/radeon_texture.c
index edfd48b..95496b1 100644
--- a/src/mesa/drivers/dri/radeon/radeon_texture.c
+++ b/src/mesa/drivers/dri/radeon/radeon_texture.c
@@ -224,7 +224,19 @@ static mesa_format
radeonChoose8888TexFormat(radeonContextPtr rmesa,
const GLuint ui = 1;
const GLubyte littleEndian = *((const GLubyte *)&ui);
- if (fbo)
+
+ /* Unfortunately, regardless the fbo flag, we might still be asked to
+ * attach a texture to a fbo later, which then won't succeed if we chose
+ * one which isn't renderable. And unlike more exotic formats, apps
aren't
+ * really prepared for the incomplete framebuffer this results in
(they'd
+ * have to retry with same internalFormat even, just different
+ * srcFormat/srcType, which can't really be expected anyway).
+ * Ideally, we'd defer format selection until later (if the texture is
+ * used as a rt it's likely there's never data uploaded to it before
attached
+ * to a fbo), but this isn't really possible, so for now just always use
+ * a renderable format.
+ */
+ if (1||fbo)
return _radeon_texformat_argb8888;
if ((srcFormat == GL_RGBA && srcType == GL_UNSIGNED_INT_8_8_8_8) ||
--
2.1.4
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
