<div dir="ltr">I've received confirmation from the HW team that the extra doubling is only needed on Haswell GT3.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 15, 2018 at 5:28 PM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The data in the commit message is a bit sketchy for Ivybridge.  We don't<br>
run dEQP or any of the CTSs on Ivybridge in CI so all the data we have<br>
is piglit.  On Haswell, piglit didn't catch anything so we don't have<br>
anything to go off of for Ivybridge besides the fact that the restriction<br>
wasn't added until Haswell.<br>
---<br>
 src/intel/blorp/blorp_clear.c | 66 ++++++++++++++++++++++++++++++++++++-------<br>
 1 file changed, 56 insertions(+), 10 deletions(-)<br>
<br>
diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c<br>
index 832e8ee..618625b 100644<br>
--- a/src/intel/blorp/blorp_clear.c<br>
+++ b/src/intel/blorp/blorp_clear.c<br>
@@ -235,16 +235,62 @@ get_fast_clear_rect(const struct isl_device *dev,<br>
       x_scaledown = x_align / 2;<br>
       y_scaledown = y_align / 2;<br>
<br>
-      /* From BSpec: 3D-Media-GPGPU Engine > 3D Pipeline > Pixel > Pixel<br>
-       * Backend > MCS Buffer for Render Target(s) [DevIVB+] > Table "Color<br>
-       * Clear of Non-MultiSampled Render Target Restrictions":<br>
-       *<br>
-       *   Clear rectangle must be aligned to two times the number of<br>
-       *   pixels in the table shown below due to 16x16 hashing across the<br>
-       *   slice.<br>
-       */<br>
-      x_align *= 2;<br>
-      y_align *= 2;<br>
+      if (ISL_DEV_IS_HASWELL(dev)) {<br>
+         /* The following text was added in the Haswell PRM, "3D Media GPGPU<br>
+          * Engine" >> "MCS Buffer for Render Target(s)" >> Table "Color Clear<br>
+          * of Non-MultiSampler Render Target Restrictions":<br>
+          *<br>
+          *    "Clear rectangle must be aligned to two times the number of<br>
+          *    pixels in the table shown below due to 16X16 hashing across the<br>
+          *    slice."<br>
+          *<br>
+          * It has persisted in the documentation for all platforms up until<br>
+          * Cannonlake and possibly even beyond.  However, we believe that it<br>
+          * is only needed on Haswell.<br>
+          *<br>
+          * There are a couple possible explanations for this restriction:<br>
+          *<br>
+          * 1) If you assume that the hardware is writing to the CCS as<br>
+          *    bytes, then the x/y_align computed above gives you an alignment<br>
+          *    in the CCS of 8x8 bytes and, if 16x16 is needed for hashing, we<br>
+          *    need to multiply by 2.<br>
+          *<br>
+          * 2) Haswell is a bit unique in that it's CCS tiling does not line<br>
+          *    up with Y-tiling on a cache-line granularity.  Instead, it has<br>
+          *    an extra bit of swizzling in bit 9.  Also, bit 6 swizzling<br>
+          *    applies to the CCS on Haswell.  This means that Haswell CTS<br>
+          *    does not match on a cache-line granularity but it does match on<br>
+          *    a 2x2 cache line granularity.<br>
+          *<br>
+          * Clearly, the first explanation seems to follow documentation the<br>
+          * best but they may be related.  In any case, empirical evidence<br>
+          * seems to confirm that it is, indeed required on Haswell.<br>
+          *<br>
+          * On Broadwell things get a bit stickier.  Broadwell adds support<br>
+          * for mip-mapped CCS with an alignment in the CCS of 256x128.  For a<br>
+          * 32bpb main surface, the above computation will yield a x/y_align<br>
+          * of 128x128 for a Y-tiled main surface and 256x64 for X-tiled.  In<br>
+          * either case, if we double the alignment, we will get an alignment<br>
+          * bigger than horizontal and vertical alignment of the CCS and fast<br>
+          * clears of one LOD may leak into others.<br>
+          *<br>
+          * Starting with Skylake, the image alignment for the CCS is only<br>
+          * 128x64 which is exactly the x/h_align computed above if the main<br>
+          * surface has a 32bpb format.  Also, the "Render Target Resolve"<br>
+          * page in the bspec (not the PRM) says, "The Resolve Rectangle size<br>
+          * is same as Clear Rectangle size from SKL+".  The x/y_align<br>
+          * computed above (without doubling) match the resolve rectangle<br>
+          * calculation perfectly.<br>
+          *<br>
+          * Finally, to confirm all this, a full test run was performed on<br>
+          * Feb. 9, 2018 with this doubling removed and the only platform<br>
+          * which seemed to be affected was Haswell.  The run consisted of<br>
+          * piglit, dEQP, the Vulkan CTS 1.0.2, the OpenGL 4.5 CTS, and the<br>
+          * OpenGL ES 3.2 CTS.<br>
+          */<br>
+         x_align *= 2;<br>
+         y_align *= 2;<br>
+      }<br>
    } else {<br>
       assert(aux_surf->usage == ISL_SURF_USAGE_MCS_BIT);<br>
<br>
-- <br>
2.5.0.400.gff86faf<br>
<br>
</blockquote></div>