<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 25, 2017 at 8:10 AM, Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Aug 18, 2017 at 11:34:40AM -0700, Jason Ekstrand wrote: > This updates the documentation on the intel CCS modifiers for a couple > of reasons: > > 1) The old documentation required that the CCS modifier only be used > with 8888 formats. While i915 currently only supports CCS scanout > with 8888 formats (and advertises such through the blob format), CCS > can be used with many other formats. Mesa, in particular, can > handle CCS on the full range of formats supported by the hardware. > For image sharing entirely within userspace, we don't want this > restriction. > > 2) The old documentation specified the scaling factor in terms of > pixels which breaks down when you start using formats which are not > 32-bit. By specifying it in terms of cache lines and tiles, we can > properly specify the scale-down relationship with no format size > assumptions. > > 3) The new comment provides more detail about the "real" layout of CCS > on Sky Lake and also points out that the reason why Y tiling is > important is because it affects row pitch calculations. > > 4) We shouldn't be documenting the Yf CCS modifier yet. Userspace is > incapable of generating it right now and we don't fully know how it > works yet. Trying to fully describe it is premature. > > Signed-off-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> > Cc: Ben Widawsky <<a href="mailto:ben@bwidawsk.net">ben@bwidawsk.net</a>> > Cc: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>> > --- > include/uapi/drm/drm_fourcc.h | 35 ++++++++++++++++++++++------------- > 1 file changed, 22 insertions(+), 13 deletions(-) > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > index 3ad838d..9670da4 100644 > --- a/include/uapi/drm/drm_fourcc.h > +++ b/include/uapi/drm/drm_fourcc.h > @@ -266,21 +266,30 @@ extern "C" { > /* > * Intel color control surface (CCS) for render compression > * > - * The framebuffer format must be one of the 8:8:8:8 RGB formats. > - * The main surface will be plane index 0 and must be Y/Yf-tiled, > - * the CCS will be plane index 1. > - * > - * Each CCS tile matches a 1024x512 pixel area of the main surface. > - * To match certain aspects of the 3D hardware the CCS is > - * considered to be made up of normal 128Bx32 Y tiles, Thus > - * the CCS pitch must be specified in multiples of 128 bytes. > - * > - * In reality the CCS tile appears to be a 64Bx64 Y tile, composed > - * of QWORD (8 bytes) chunks instead of OWORD (16 bytes) chunks. > - * But that fact is not relevant unless the memory is accessed > - * directly. > + * The image format must be compatible with CCS_E (lossless render > + * compression) as specified in the PRM for the relevant hardware. > + * The main surface will be plane index 0 and must be Y-tiled, > + * the CCS will be plane index 1 and is also Y-tiled. > + * > + * Each 64B cache line in the CCS (a region of 16B x 4 rows when > + * Y-tiled) corresponds to a region of 32x16 cache lines in the main > + * surface. (As a corollary, each CCS tile corresponds to an area of > + * 32x16 tiles in the main surface.) This relationship holds regardless > + * of the size of the number of bits per pixel of the image format. > + * > + * In reality, the cache lines in the CCS tile are proportioned in an > + * 8B x 8 row configuration with each byte being 2x2 2-bit CCS entries. > + * However, CCS is documented as Y-tiled with the scaling relationship > + * described in terms of cache lines as above so we consider it to be > + * Y-tiled for the purpose of specifying this modifier. This means that > + * the row pitch for the CCS assumes 128B/tile. > */ > #define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4) > + > +/* Reserved for the Yf version of the TILED_CCS modifier. > + * > + * Exact definition TBD. > + */ </div></div>IIRC the same explanation can be used for both Y and Yf. The CCS surface is still using the wonky Y tile layout even if the main surface is Yf. </blockquote></div></div><div class="gmail_extra"> </div><div class="gmail_extra">My reading of the docs indicates that the cache line correlation above holds even for Yf and Ys. However, I'm reluctant to base too much off your R-E work because it was, as far as I know, entirely done with 32-bit formats. For 32-bit formats, Yf and Y have the same tile size. The only difference is that the cache lines are swizzled about a bit more with Yf. I'd like to confirm with some 64 and 128-bit formats before trying to spec it.</div><div class="gmail_extra"> </div><div class="gmail_extra">--Jason </div></div>