Re: [Mesa-dev] [PATCH 5/5] i965/gen9: Don't allow the RGBX formats for texturing/rendering

[Anuj Phogat]

On Mon, Nov 23, 2015 at 3:00 AM, Neil Roberts  wrote:
> Ben Widawsky  writes:
>
>>> +   /* The RGBX formats are not renderable. Normally these get mapped
>>> +* internally to RGBA formats when rendering. However on Gen9+ when this
>>> +* internal override is used fast clears don't work so they are 
>>> disabled in
>>> +* brw_meta_fast_clear. To avoid this problem we can just pretend not to
>>> +* support RGBX formats at all. This will cause the upper layers of 
>>> Mesa to
>>> +* pick the RGBA formats instead. This works fine because when it is 
>>> used
>>
>> A lot of these formats are already unsupported for fast clears. In fact, I
>> believe only MESA_FORMAT_R8G8B8X8_UNORM is a problem. Are you trying to
>> accomplish something else here as well?
>
> I tested all of the formats with the fast-clear Piglit test and I think
> all of them are supported for fast clears on MSRTs. Don't forget that
> the ccs_e field in the surface_format_info isn't used for MSRTs. The
> first three do actually cause failures but for some reason
> MESA_FORMAT_RGBX_FLOAT16 does actually work. MESA_FORMAT_RGBX_FLOAT32
> isn't used because there is no override to make it use
> MESA_FORMAT_RGBA_FLOAT32 as a render target anyway. Presumably that
> means it will end up using RGBA for sampling as well and there are
> probably going to be some bugs with this format on platforms without
> texture swizzle or that the use the blorp so it probably should have
> this override. However I think that is a separate patch. If we did fix
> that then it would make sense to leave this format in this patch.
>
> Regards,
> - Neil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Looks like the right thing to do.

Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] i965/gen9: Don't allow the RGBX formats for texturing/rendering

[Neil Roberts]

Ben Widawsky  writes:

>> +   /* The RGBX formats are not renderable. Normally these get mapped
>> +* internally to RGBA formats when rendering. However on Gen9+ when this
>> +* internal override is used fast clears don't work so they are disabled 
>> in
>> +* brw_meta_fast_clear. To avoid this problem we can just pretend not to
>> +* support RGBX formats at all. This will cause the upper layers of Mesa 
>> to
>> +* pick the RGBA formats instead. This works fine because when it is used
>
> A lot of these formats are already unsupported for fast clears. In fact, I
> believe only MESA_FORMAT_R8G8B8X8_UNORM is a problem. Are you trying to
> accomplish something else here as well?

I tested all of the formats with the fast-clear Piglit test and I think
all of them are supported for fast clears on MSRTs. Don't forget that
the ccs_e field in the surface_format_info isn't used for MSRTs. The
first three do actually cause failures but for some reason
MESA_FORMAT_RGBX_FLOAT16 does actually work. MESA_FORMAT_RGBX_FLOAT32
isn't used because there is no override to make it use
MESA_FORMAT_RGBA_FLOAT32 as a render target anyway. Presumably that
means it will end up using RGBA for sampling as well and there are
probably going to be some bugs with this format on platforms without
texture swizzle or that the use the blorp so it probably should have
this override. However I think that is a separate patch. If we did fix
that then it would make sense to leave this format in this patch.

Regards,
- Neil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/5] i965/gen9: Don't allow the RGBX formats for texturing/rendering

[Ben Widawsky]

On Thu, Nov 19, 2015 at 04:25:21PM +0100, Neil Roberts wrote:
> The RGBX surface formats aren't renderable so we internally remap them
> to RGBA when rendering. They are retained as RGBX when used as
> textures. However since the previous patch fast clears are disabled
> for surfaces that use a different format for rendering than for
> texturing. To avoid this situation we can just pretend not to support
> RGBX formats at all. This will cause the upper layers of mesa to pick
> an RGBA format internally instead. This should be safe because we
> always override the alpha component to 1.0 for RGBX in the texture
> swizzle anyway. We could also do this for all gens except that it's a
> bit more difficult when the hardware doesn't support texture
> swizzling. Gens using the blorp have further problems because that
> doesn't implement this swizzle override.
> ---
>  src/mesa/drivers/dri/i965/brw_surface_formats.c | 28 
> +
>  1 file changed, 28 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
> b/src/mesa/drivers/dri/i965/brw_surface_formats.c
> index 7c38431..7594aca 100644
> --- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
> +++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
> @@ -733,6 +733,34 @@ brw_init_surface_formats(struct brw_context *brw)
> if (brw->gen >= 8)
>ctx->TextureFormatSupported[MESA_FORMAT_Z_UNORM16] = true;
>  
> +   /* The RGBX formats are not renderable. Normally these get mapped
> +* internally to RGBA formats when rendering. However on Gen9+ when this
> +* internal override is used fast clears don't work so they are disabled 
> in
> +* brw_meta_fast_clear. To avoid this problem we can just pretend not to
> +* support RGBX formats at all. This will cause the upper layers of Mesa 
> to
> +* pick the RGBA formats instead. This works fine because when it is used

A lot of these formats are already unsupported for fast clears. In fact, I
believe only MESA_FORMAT_R8G8B8X8_UNORM is a problem. Are you trying to
accomplish something else here as well?

> +* as a texture source the swizzle state is programmed to force the alpha
> +* channel to 1.0 anyway. We could also do this for all gens except that
> +* it's a bit more difficult when the hardware doesn't support texture
> +* swizzling. Gens using the blorp have further problems because that
> +* doesn't implement this swizzle override. We don't need to do this for
> +* BGRX because that actually is supported natively on Gen8+.
> +*/
> +   if (brw->gen >= 9) {
> +  static const mesa_format rgbx_formats[] = {
> + MESA_FORMAT_R8G8B8X8_UNORM,
> + MESA_FORMAT_R8G8B8X8_SRGB,
> + MESA_FORMAT_RGBX_UNORM16,
> + MESA_FORMAT_RGBX_FLOAT16,
> + MESA_FORMAT_RGBX_FLOAT32
> +  };
> +
> +  for (int i = 0; i < ARRAY_SIZE(rgbx_formats); i++) {
> + ctx->TextureFormatSupported[rgbx_formats[i]] = false;
> + brw->format_supported_as_render_target[rgbx_formats[i]] = false;
> +  }
> +   }
> +


> /* On hardware that lacks support for ETC1, we map ETC1 to RGBX
>  * during glCompressedTexImage2D(). See intel_mipmap_tree::wraps_etc1.
>  */
> -- 
> 1.9.3
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/5] i965/gen9: Don't allow the RGBX formats for texturing/rendering

[Neil Roberts]

The RGBX surface formats aren't renderable so we internally remap them
to RGBA when rendering. They are retained as RGBX when used as
textures. However since the previous patch fast clears are disabled
for surfaces that use a different format for rendering than for
texturing. To avoid this situation we can just pretend not to support
RGBX formats at all. This will cause the upper layers of mesa to pick
an RGBA format internally instead. This should be safe because we
always override the alpha component to 1.0 for RGBX in the texture
swizzle anyway. We could also do this for all gens except that it's a
bit more difficult when the hardware doesn't support texture
swizzling. Gens using the blorp have further problems because that
doesn't implement this swizzle override.
---
 src/mesa/drivers/dri/i965/brw_surface_formats.c | 28 +
 1 file changed, 28 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_surface_formats.c 
b/src/mesa/drivers/dri/i965/brw_surface_formats.c
index 7c38431..7594aca 100644
--- a/src/mesa/drivers/dri/i965/brw_surface_formats.c
+++ b/src/mesa/drivers/dri/i965/brw_surface_formats.c
@@ -733,6 +733,34 @@ brw_init_surface_formats(struct brw_context *brw)
if (brw->gen >= 8)
   ctx->TextureFormatSupported[MESA_FORMAT_Z_UNORM16] = true;
 
+   /* The RGBX formats are not renderable. Normally these get mapped
+* internally to RGBA formats when rendering. However on Gen9+ when this
+* internal override is used fast clears don't work so they are disabled in
+* brw_meta_fast_clear. To avoid this problem we can just pretend not to
+* support RGBX formats at all. This will cause the upper layers of Mesa to
+* pick the RGBA formats instead. This works fine because when it is used
+* as a texture source the swizzle state is programmed to force the alpha
+* channel to 1.0 anyway. We could also do this for all gens except that
+* it's a bit more difficult when the hardware doesn't support texture
+* swizzling. Gens using the blorp have further problems because that
+* doesn't implement this swizzle override. We don't need to do this for
+* BGRX because that actually is supported natively on Gen8+.
+*/
+   if (brw->gen >= 9) {
+  static const mesa_format rgbx_formats[] = {
+ MESA_FORMAT_R8G8B8X8_UNORM,
+ MESA_FORMAT_R8G8B8X8_SRGB,
+ MESA_FORMAT_RGBX_UNORM16,
+ MESA_FORMAT_RGBX_FLOAT16,
+ MESA_FORMAT_RGBX_FLOAT32
+  };
+
+  for (int i = 0; i < ARRAY_SIZE(rgbx_formats); i++) {
+ ctx->TextureFormatSupported[rgbx_formats[i]] = false;
+ brw->format_supported_as_render_target[rgbx_formats[i]] = false;
+  }
+   }
+
/* On hardware that lacks support for ETC1, we map ETC1 to RGBX
 * during glCompressedTexImage2D(). See intel_mipmap_tree::wraps_etc1.
 */
-- 
1.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev