We have implicitly been not advertising these formats since we had them
turned off in the format capabilities table. We are about to update that
table and this prevents a change in behavior. The only change in behavior
created by this patch is that we no longer advertise support for
R16G16B16_FLOAT which means that it's now renderable which seems like a
bonus. Maybe someday we'll want to change things to start supporting
16-bit RGB formats natively but, at the moment, there's no need.
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 2543f4b..69d3bd4 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -311,6 +311,16 @@ brw_init_surface_formats(struct brw_context *brw)
if (texture == 0 && format != MESA_FORMAT_RGBA_FLOAT32)
continue;
+ /* Don't advertisel 8 and 16-bit RGB formats to core mesa. This ensures
+ * that they are renderable from an API perspective since core mesa will
+ * fall back to RGBA or RGBX (we can't render to non-power-of-two
+ * formats). For 8-bit, formats, this also keeps us from hitting some
+ * nasty corners in intel_miptree_map_blit if you ever try to map one.
+ */
+ int format_size = _mesa_get_format_bytes(format);
+ if (format_size == 3 || format_size == 6)
+ continue;
+
if (isl_format_supports_sampling(devinfo, texture) &&
(isl_format_supports_filtering(devinfo, texture) || is_integer))
ctx->TextureFormatSupported[format] = true;
--
2.5.0.400.gff86faf
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
