[Intel-gfx] [PATCH] tests/kms_ccs: Fix the color/ccs surface generation

[Jason Ekstrand]

On Fri, Aug 4, 2017 at 8:42 AM, Daniel Stone <daniel at fooishbar.org> wrote:

> On 4 August 2017 at 15:56, Jason Ekstrand <jason at jlekstrand.net> wrote:
> > On August 4, 2017 2:59:56 AM Daniel Stone <daniel at fooishbar.org> wrote:
> >>> +               width = ALIGN(f.width * 4, 32) / 32;
> >>> +               height = ALIGN(f.height, 16) / 16;
> >>> +               f.pitches[1] = ALIGN(width * 1, 128);
> >>>                 f.modifier[1] = modifier;
> >>>                 f.offsets[1] = size[0];
> >>> -               size[1] = f.pitches[1] * ALIGN(height, 64);
> >>> +               size[1] = f.pitches[1] * ALIGN(height, 32);
> >>
> >>
> >> I changed this to f.height rather than height, because otherwise the
> >> kernel was rejecting the aux buffer for being too small.
> >
> > Congratulations, you found a bug in the kernel branch you're running.
> The
> > downsized height is definitely what we want and it works fine with my
> kernel
> > branch.
>
> Great. Which kernel are you running then? I'm running from here:
> https://git.collabora.com/cgit/user/daniels/linux.git/refs/heads
>

I'm working from some branch I got from Ville a couple months ago.


> Currently we have hsub/vsub defined as 16/8 (Vidya inverted this, but
> I never got a clear answer on why),


Here's my comment in the IGT test:

        /* From the Sky Lake PRM, Vol 12, "Color Control Surface":
         *
         *    "The compression state of the cache-line pair is
         *    specified by 2 bits in the CCS.  Each CCS cache-line
         *    represents an area on the main surface of 16x16 sets
         *    of 128 byte Y-tiled cache-line-pairs. CCS is always Y
         *    tiled."
         *
         * A "cache-line-pair" for a Y-tiled surface is two
         * horizontally adjacent cache lines.  When operating in
         * bytes and rows, this gives us a scale-down factor of
         * 32x16.  Since the main surface has a 32-bit format, we
         * need to multiply width by 4 to get bytes.
         */

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.

tile_width as 128, and tile_height
> comes out as 32.


Yes, that's a correct Y-tile.


> Given the calculations in intel_fill_fb_info, I come
> out with the kernel demanding either 34816 bytes for CCS (using 16/8
> hsub/vsub), or 20480 bytes (8/16) for a 1920x1080 framebuffer.


Neither of those look right.  I'm getting 6 pages, or 24576B when I run the
test which should be correct.


> Which
> kernel do you have, and how are you coming out with that calculation?
> Do we need to go back and re-figure out what pitch is?
>
> FWIW, ISL seems to get it right, according to the kernel.
>

Weird...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20170804/de5277f5/attachment.html>