From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jason Ekstrand <jason@jlekstrand.net>
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: Wed, 10 Jan 2018 19:48:13 +0200 [thread overview]
Message-ID: <20180110174813.GW10981@intel.com> (raw)
In-Reply-To: <CAOFGe96MEEHsaXFMCpMH5Uzp102C2VBCcKieSJ17p_hT5K=Hqw@mail.gmail.com>
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.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-01-10 17:48 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ä [this message]
2018-01-12 5:25 ` Jason Ekstrand
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=20180110174813.GW10981@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=ben@bwidawsk.net \
--cc=daniels@collabora.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jason@jlekstrand.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox