<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 21, 2017 at 12:27 PM, Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quoting Jason Ekstrand (2017-07-21 20:11:27)<br>
<span class="">> +   if (surf_info->usage & ISL_SURF_USAGE_BLIT_BIT) {<br>
> +      /* According to the Ivy Bridge PRM, Vol1 Part4, section 1.2.1.2<br>
> +       * (Graphics Data Size Limitations):<br>
> +       *<br>
> +       *    The BLT engine is capable of transferring very large quantities of<br>
> +       *    graphics data. Any graphics data read from and written to the<br>
> +       *    destination is permitted to represent a number of pixels that<br>
> +       *    occupies up to 65,536 scan lines and up to 32,768 bytes per scan<br>
> +       *    line at the destination. The maximum number of pixels that may be<br>
> +       *    represented per scan line’s worth of graphics data depends on the<br>
> +       *    color depth.<br>
> +       *<br>
> +       * The blitter's pitch is a signed 16-bit integer, but measured in bytes<br>
> +       * for linear surfaces and DWords for tiled surfaces.  So the maximum<br>
> +       * pitch is 32k linear and 128k tiled.<br>
> +       */<br>
> +      const uint32_t blt_pitch =<br>
> +         tile_info->tiling == ISL_TILING_LINEAR ? row_pitch : row_pitch / 4;<br>
> +      if (blt_pitch > 32768)<br>
> +         return false;<br>
<br>
</span>Ben will probably remember better since he did the same limits for GL,<br>
but isn't the field for pitch in XY_SRC_COPY a s16 (as it allows<br>
negative pitches)? So that test should be >= 32768.</blockquote><div><br></div><div>Yes, yes it should.<br></div><div><br></div><div>Also, I did some more reading and it's not a pitch restriction at all.  It's a restriction on base address.  The only reason why we treat it as a pitch restriction in GL is because that ensures that most miplevels are aligned to 64 bits (not all!) and got us to not notice the real problem.<br><br></div><div>--Jason <br></div></div></div></div>