All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Ekstrand <jason@jlekstrand.net>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
	Ben Widawsky <ben@bwidawsk.net>,
	Daniel Stone <daniels@collabora.com>
Subject: Re: [PATCH 1/8] drm/i915: Add a comment exlaining CCS hsub/vsub
Date: Thu, 11 Jan 2018 21:25:47 -0800	[thread overview]
Message-ID: <CAOFGe97N6z-0N=b5-sHk-4LHegW0TwKSnbbeTaSqTMT-oCd9TQ@mail.gmail.com> (raw)
In-Reply-To: <20180110174813.GW10981@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 3789 bytes --]

On Wed, Jan 10, 2018 at 9:48 AM, Ville Syrjälä <
ville.syrjala@linux.intel.com> wrote:

> On Wed, Jan 10, 2018 at 09:03:14AM -0800, Jason Ekstrand wrote:
> > On Fri, Dec 22, 2017 at 11:22 AM, Ville Syrjala <
> > ville.syrjala@linux.intel.com> wrote:
> >
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > Let's document why we claim hsub==8,vsub==16 for CCS even though the
> > > memory layout would suggest that we use 16x8 instead.
> > >
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Ben Widawsky <ben@bwidawsk.net>
> > > Cc: Jason Ekstrand <jason@jlekstrand.net>
> > > Cc: Daniel Stone <daniels@collabora.com>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 0cd355978ab4..83aec68537b4 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2387,6 +2387,13 @@ static unsigned int intel_fb_modifier_to_tiling(
> uint64_t
> > > fb_modifier)
> > >         }
> > >  }
> > >
> > > +/*
> > > + * 1 byte of CCS actually corresponds to 16x8 pixels on the main
> > > + * surface, and the memory layout for the CCS tile is 64x64 bytes.
> > > + * But since we're pretending the CCS tile is 128 bytes wide we
> > > + * adjust hsub/vsub here accordingly to 8x16 so that the
> > > + * bytes<->x/y conversions come out correct.
> > >
> >
> > I'm not particularly happy with this comment as I think it pushes the
> > mental model for these calculations in the wrong direction.  The PRM
> says:
> >
> > The Color Control Surface (CCS) contains the compression status of the
> > cache-line pairs. 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 16 x16 sets of 128 byte Y-tiled
> > cache-line-pairs. CCS is always Y tiled.
> >
> > If you understand that a "cache line pair" in the main surface is a
> > horizontally adjacent cache line pair (cl1_addr = cl0_addr + 512) and you
> > just accept the statement about Y-tiling, this is the correct
> calculation.
> > Calculating these things in terms of pixels is occasionally useful but is
> > the wrong mental model.  The cache line statement above both accurately
> > describes the layout of the CCS (at the cache line granularity) and
> scales
> > to other pixel formats which are not 32-bit.
> >
> > I know that Ville and I have disagreed on this in the past but I don't
> > think adding comments about how we're "pretending the CCS tile is 128
> bytes
> > wide" is making anything more clear.
>
> I don't really see how talk about cachelines is going to help explain
> the hsub/vsub values we use here.
>
> But I don't really care that much. We could just leave them as magic
> numbers if no one can come up with a clear explanation for them.
>

How about a comment like this:

/*From the Sky Lake PRM:
 *
 *    The Color Control Surface (CCS) contains the compression status of
the cache-line pairs. 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 16 x16 sets of 128 byte Y-tiled
cache-line-pairs. CCS is always Y tiled.
 *
 * Since cache line pairs refers to horizontally adjacent cache lines, each
cache line in the CCS
 * corresponds to an area of 32x16 cache lines on the main surface.  Since
each pixel is 4 bytes,
 * this gives us a ratio of one byte in the CCS for each 8x16 pixels in the
main surface.
 */

[-- Attachment #1.2: Type: text/html, Size: 5195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-01-12  5:25 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-22 19:22 [PATCH v2 0/8] drm/i915: Fix up the CCS code Ville Syrjala
2017-12-22 19:22 ` [PATCH 1/8] drm/i915: Add a comment exlaining CCS hsub/vsub Ville Syrjala
2018-01-10 12:59   ` Daniel Vetter
2018-01-10 17:03   ` Jason Ekstrand
2018-01-10 17:48     ` Ville Syrjälä
2018-01-12  5:25       ` Jason Ekstrand [this message]
2018-01-17 20:20         ` Ville Syrjälä
2018-01-17 22:05           ` Jason Ekstrand
2018-01-19 14:41   ` [PATCH v2 " Ville Syrjala
2018-01-20 17:39     ` Jason Ekstrand
2018-01-24 18:18       ` Ville Syrjälä
2017-12-22 19:22 ` [PATCH 2/8] drm/i915: Nuke a pointless unreachable() Ville Syrjala
2018-01-10 12:58   ` Daniel Vetter
2017-12-22 19:22 ` [PATCH v2 3/8] drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites Ville Syrjala
2017-12-22 20:42   ` Daniel Stone
2018-01-10 12:59   ` Daniel Vetter
2018-01-17 20:01     ` Ville Syrjälä
2017-12-22 19:22 ` [PATCH 4/8] drm/i915: Clean up the sprite modifier checks Ville Syrjala
2018-01-10 13:12   ` Daniel Vetter
2017-12-22 19:22 ` [PATCH 5/8] drm/i915: Add CCS capability for sprites Ville Syrjala
2017-12-27 11:10   ` Mika Kahola
2017-12-22 19:22 ` [PATCH 6/8] drm/i915: Allow up to 32KB stride on SKL+ "sprites" Ville Syrjala
2018-01-10 13:03   ` Daniel Vetter
2018-01-17 20:18     ` Ville Syrjälä
2017-12-22 19:22 ` [PATCH 7/8] drm: Check that the plane supports the request format+modifier combo Ville Syrjala
2018-01-10 13:04   ` [Intel-gfx] " Daniel Vetter
2018-02-26 14:43     ` Ville Syrjälä
2017-12-22 19:22 ` [PATCH 8/8] drm/i915: Remove the pipe/plane ID checks from skl_check_ccs_aux_surface() Ville Syrjala
2017-12-27 11:33   ` Mika Kahola
2017-12-22 20:31 ` ✓ Fi.CI.BAT: success for drm/i915: Fix up the CCS code (rev2) Patchwork
2017-12-22 22:39 ` ✗ Fi.CI.IGT: warning " Patchwork
2018-01-19 15:32 ` ✗ Fi.CI.BAT: failure for drm/i915: Fix up the CCS code (rev3) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOFGe97N6z-0N=b5-sHk-4LHegW0TwKSnbbeTaSqTMT-oCd9TQ@mail.gmail.com' \
    --to=jason@jlekstrand.net \
    --cc=ben@bwidawsk.net \
    --cc=daniels@collabora.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.