<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 4, 2017 at 8:42 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 4 August 2017 at 15:56, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> On August 4, 2017 2:59:56 AM Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<br>
</span><span class="gmail-">>>> + width = ALIGN(f.width * 4, 32) / 32;<br>
>>> + height = ALIGN(f.height, 16) / 16;<br>
>>> + f.pitches[1] = ALIGN(width * 1, 128);<br>
>>> f.modifier[1] = modifier;<br>
>>> f.offsets[1] = size[0];<br>
>>> - size[1] = f.pitches[1] * ALIGN(height, 64);<br>
>>> + size[1] = f.pitches[1] * ALIGN(height, 32);<br>
>><br>
>><br>
>> I changed this to f.height rather than height, because otherwise the<br>
>> kernel was rejecting the aux buffer for being too small.<br>
><br>
> Congratulations, you found a bug in the kernel branch you're running. The<br>
> downsized height is definitely what we want and it works fine with my kernel<br>
> branch.<br>
<br>
</span>Great. Which kernel are you running then? I'm running from here:<br>
<a href="https://git.collabora.com/cgit/user/daniels/linux.git/refs/heads" rel="noreferrer" target="_blank">https://git.collabora.com/<wbr>cgit/user/daniels/linux.git/<wbr>refs/heads</a><br></blockquote><div><br></div><div>I'm working from some branch I got from Ville a couple months ago.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Currently we have hsub/vsub defined as 16/8 (Vidya inverted this, but<br>
I never got a clear answer on why),</blockquote><div> <div>Here's my comment in the IGT test:<br><br> /* From the Sky Lake PRM, Vol 12, "Color Control Surface":<br> *<br> * "The compression state of the cache-line pair is<br> * specified by 2 bits in the CCS. Each CCS cache-line<br> * represents an area on the main surface of 16x16 sets<br> * of 128 byte Y-tiled cache-line-pairs. CCS is always Y<br> * tiled."<br> *<br> * A "cache-line-pair" for a Y-tiled surface is two<br> * horizontally adjacent cache lines. When operating in<br> * bytes and rows, this gives us a scale-down factor of<br> * 32x16. Since the main surface has a 32-bit format, we<br> * need to multiply width by 4 to get bytes.<br> */<br><br></div>We
have a scaling factor, in bytes, of 32x16. However, the main surface
uses 4 byes per pixel so we need to account for that. In the IGT test,
we multiply the width of the main surface by 4 to get bytes.
Alternatively, you can adjust the scale factor to 8x16 so long as you
align things correctly.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> tile_width as 128, and tile_height<br>
comes out as 32.</blockquote><br></div><div class="gmail_quote">Yes, that's a correct Y-tile.<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Given the calculations in intel_fill_fb_info, I come<br>
out with the kernel demanding either 34816 bytes for CCS (using 16/8<br>
hsub/vsub), or 20480 bytes (8/16) for a 1920x1080 framebuffer.</blockquote><div><br></div><div>Neither of those look right. I'm getting 6 pages, or 24576B when I run the test which should be correct.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Which<br>
kernel do you have, and how are you coming out with that calculation?<br>
Do we need to go back and re-figure out what pitch is?<br>
<br>
FWIW, ISL seems to get it right, according to the kernel.<br></blockquote><div><br></div><div>Weird... <br></div></div></div></div>