[PATCH v2 9/9] drm/i915: Add render decompression support

[Ville Syrjälä]

On Wed, Mar 01, 2017 at 09:50:56AM -0800, Ben Widawsky wrote:
> On 17-03-01 12:51:17, Ville Syrjälä wrote:
> >On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:
> >> On 17-02-28 12:18:39, Jason Ekstrand wrote:
> ><snip>
> >> >I've said it before but reading through Ben's patches again make me want to
> >> >be peskier about it.  I would really like the UABI to treat the CCS as if
> >> >it's Y-tiled with a tile size of 128B x 32 rows.  Why?  Because this is
> >> >what all the docs say it is.  From the display docs for "Color Control
> >> >Surface":
> >> >
> >> >"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."
> >> >
> >> >This contains 95% of the information needed to know the relation between
> >> >the CCS and the main surface.  The other 5% (which is badly documented) is
> >> >that cache line pairs are horizontally adjacent.  This gives a relationship
> >> >of one cache line in the CCS maps to 32x64 cache lines in the main surface.
> >> >
> >> >But it's not actually Y-tiled?  Of course not.  I've worked out the exact
> >> >tiling and it looks something like Y but isn't quite the same.  However,
> >> >this isn't unique to CCS.  Stencil (W-tiled), HiZ, and gen7-8
> >> >single-sampled MCS also each have their own tiling (Haswell MCS is
> >> >especially exotic) but the docs call all of them Y-tiled and I think the
> >> >hardware internally treats them as Y-tiled with the cache lines shuffled
> >> >around a bit.
> >> >
> >> >Given the fact that they seem to like to change the MCS/CCS tiling around
> >> >on every hardware generation, I'm reluctant to base UABI on the fact that
> >> >the CCS appears to have 64x64 "pixels" per tile with each "pixel"
> >> >corresponding to 16x8 pixels in the color surface.  That's not what we had
> >> >on any previous gen and may change on gen10 for no aparent reason.  I'd
> >> >much rather base it on Y-tiling and a relationship between cache lines
> >> >which, even if they change the exact swizzle on gen10, will probably remain
> >> >the same.  (For the gen7-8 analogue of CCS, they changed the tiling every
> >> >generation but the relationship of one MCS cache line maps to 32x128 color
> >> >cache lines remained the same).
> >> >
> >> >Ok, I've said my peice.  If we have to divide by 2 in userspace, we won't
> >> >die, but I'd like to get the UABI right before we chissel it in stone.
> >> >
> >> >--Jason
> >> >
> >> >
> >>
> >> I vote we make the stride in units of tiles when we have the CCS modifier.
> >
> >That won't fly with the KMS API. I suppose I could make the tile 128 bytes
> >wide by swapping the "1 byte == 16x8 pixels" notion with a
> >"1 byte == 8x16 pixels" notion. Doesn't match the actual truth anymore,
> >but I guess no one really cares.
> >
> 
> KMS API goes right out the window with modifiers. Isn't that really the whole
> point of modifiers?

Not in my opinion. It's just a mild extension. The basics still apply
perfectly fine. 

And I really don't want to add special exceptions for CCS since
that'll just mean more code and more bugs. Right now the same code
that works for your typical planar formats works for CCS as well.

-- 
Ville Syrjälä
Intel OTC