[Mesa-dev] [PATCH 21/27] intel/isl/gen7: Add CCS alignment restrictions

Jason Ekstrand jason at jlekstrand.net
Sat Jan 21 00:15:17 UTC 2017


On Mon, Jan 16, 2017 at 1:13 AM, Topi Pohjolainen <
topi.pohjolainen at gmail.com> wrote:

> Gen8 and Gen9 are already more heavily constrained as one
> applies arrayed/mipmapped alignment even for non-arrayed and
> non-mipmapped.
>
> Signed-off-by: Topi Pohjolainen <topi.pohjolainen at intel.com>
> ---
>  src/intel/isl/isl_gen7.c | 39 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
>
> diff --git a/src/intel/isl/isl_gen7.c b/src/intel/isl/isl_gen7.c
> index 18687b5..b1874c1 100644
> --- a/src/intel/isl/isl_gen7.c
> +++ b/src/intel/isl/isl_gen7.c
> @@ -403,6 +403,45 @@ isl_gen7_choose_image_alignment_el(const struct
> isl_device *dev,
>     /* IVB+ does not support combined depthstencil. */
>     assert(!isl_surf_usage_is_depth_and_stencil(info->usage));
>
> +   const struct isl_format_layout *fmtl = isl_format_get_layout(info->
> format);
> +   if (fmtl->txc == ISL_TXC_CCS) {
> +      assert(tiling == ISL_TILING_CCS);
> +
> +      /*
> +       * IvyBrigde PRM Vol 2, Part 1, "11.7 MCS Buffer for Render
> Target(s)":
> +       *
> +       *  The following table describes the RT alignment
> +       *                        Pixels   Lines
> +       *  TiledY RT CL
> +       *  bpp
> +       *  32                      8        4
> +       *  64                      4        4
> +       *  128                     2        4
> +       */
>

This isn't quite correct... Yes, the table above describes the horizontal
and vertical alignment of the single-sampled MCS on Ivy Bridge.  However,
ISL already takes care of this for us by its choice of block sizes.  Each
of the CCS formats is a "compressed" format with a block size that exactly
matches the alignment given in the table.  Since the alignment returned by
this function is in units of *elements*, the correct value should be 1x1
for all CCS formats on gen7.  For instance, GEN7_CCS_32BPP_Y is a
compressed format with a block size of 8x4 pixels per element and a 1x1el
alignment becomes 8x4px.  Does that make sense?  It's a bit subtle.


> +      switch (fmtl->format) {
> +      case ISL_FORMAT_GEN7_CCS_32BPP_X:
> +         *image_align_el = isl_extent3d(8, 4, 1);
> +         return;
> +      case ISL_FORMAT_GEN7_CCS_64BPP_X:
> +         *image_align_el = isl_extent3d(4, 4, 1);
> +         return;
> +      case ISL_FORMAT_GEN7_CCS_128BPP_X:
> +         *image_align_el = isl_extent3d(2, 4, 1);
> +         return;
> +      case ISL_FORMAT_GEN7_CCS_32BPP_Y:
> +         *image_align_el = isl_extent3d(8, 4, 1);
> +         return;
> +      case ISL_FORMAT_GEN7_CCS_64BPP_Y:
> +         *image_align_el = isl_extent3d(4, 4, 1);
> +         return;
> +      case ISL_FORMAT_GEN7_CCS_128BPP_Y:
> +         *image_align_el = isl_extent3d(2, 4, 1);
> +         return;
> +      default:
> +         unreachable("Invalid CCS format");
> +      }
> +   }
> +
>     *image_align_el = (struct isl_extent3d) {
>        .w = gen7_choose_halign_el(dev, info),
>        .h = gen7_choose_valign_el(dev, info, tiling),
> --
> 2.5.5
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170120/8401becd/attachment-0001.html>


More information about the mesa-dev mailing list