Re: [Mesa-dev] [PATCH 5/5] i965/gen9: Don't allow the RGBX formats for texturing/rendering
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
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
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
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