On Fri, Aug 4, 2017 at 8:42 AM, Daniel Stone <dan...@fooishbar.org> wrote:
> On 4 August 2017 at 15:56, Jason Ekstrand <ja...@jlekstrand.net> wrote: > > On August 4, 2017 2:59:56 AM Daniel Stone <dan...@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...
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx