<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 21, 2017 at 9:25 AM, Ben Widawsky <span dir="ltr"><<a href="mailto:ben@bwidawsk.net" target="_blank">ben@bwidawsk.net</a>></span> wrote:<br><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 17-08-18 11:34:40, Jason Ekstrand wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This updates the documentation on the intel CCS modifiers for a couple<br>
of reasons:<br>
<br>
1) The old documentation required that the CCS modifier only be used<br>
with 8888 formats. While i915 currently only supports CCS scanout<br>
with 8888 formats (and advertises such through the blob format), CCS<br>
can be used with many other formats. Mesa, in particular, can<br>
handle CCS on the full range of formats supported by the hardware.<br>
For image sharing entirely within userspace, we don't want this<br>
restriction.<br>
<br>
2) The old documentation specified the scaling factor in terms of<br>
pixels which breaks down when you start using formats which are not<br>
32-bit. By specifying it in terms of cache lines and tiles, we can<br>
properly specify the scale-down relationship with no format size<br>
assumptions.<br>
<br>
3) The new comment provides more detail about the "real" layout of CCS<br>
on Sky Lake and also points out that the reason why Y tiling is<br>
important is because it affects row pitch calculations.<br>
<br>
4) We shouldn't be documenting the Yf CCS modifier yet. Userspace is<br>
incapable of generating it right now and we don't fully know how it<br>
works yet. Trying to fully describe it is premature.<br>
<br>
Signed-off-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>><br>
Cc: Ben Widawsky <<a href="mailto:ben@bwidawsk.net" target="_blank">ben@bwidawsk.net</a>><br>
Cc: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a><wbr>><br>
---<br>
include/uapi/drm/drm_fourcc.h | 35 ++++++++++++++++++++++--------<wbr>-----<br>
1 file changed, 22 insertions(+), 13 deletions(-)<br>
<br>
diff --git a/include/uapi/drm/drm_fourcc.<wbr>h b/include/uapi/drm/drm_fourcc.<wbr>h<br>
index 3ad838d..9670da4 100644<br>
--- a/include/uapi/drm/drm_fourcc.<wbr>h<br>
+++ b/include/uapi/drm/drm_fourcc.<wbr>h<br>
@@ -266,21 +266,30 @@ extern "C" {<br>
/*<br>
* Intel color control surface (CCS) for render compression<br>
*<br>
- * The framebuffer format must be one of the 8:8:8:8 RGB formats.<br>
- * The main surface will be plane index 0 and must be Y/Yf-tiled,<br>
- * the CCS will be plane index 1.<br>
- *<br>
- * Each CCS tile matches a 1024x512 pixel area of the main surface.<br>
- * To match certain aspects of the 3D hardware the CCS is<br>
- * considered to be made up of normal 128Bx32 Y tiles, Thus<br>
- * the CCS pitch must be specified in multiples of 128 bytes.<br>
- *<br>
- * In reality the CCS tile appears to be a 64Bx64 Y tile, composed<br>
- * of QWORD (8 bytes) chunks instead of OWORD (16 bytes) chunks.<br>
- * But that fact is not relevant unless the memory is accessed<br>
- * directly.<br>
+ * The image format must be compatible with CCS_E (lossless render<br>
+ * compression) as specified in the PRM for the relevant hardware.<br>
+ * The main surface will be plane index 0 and must be Y-tiled,<br>
+ * the CCS will be plane index 1 and is also Y-tiled.<br>
</blockquote>
<br></div></div>
I guess if you're future proofing, you might want to bake in the language for<br>
planar formats.<span class=""><br></span></blockquote><div><br></div><div>What language are you looking for. It's simply not allowed. Maybe I should say something like "the image format must non-planar and compatible with CCS_E..."<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+ *<br>
+ * Each 64B cache line in the CCS (a region of 16B x 4 rows when<br>
+ * Y-tiled) corresponds to a region of 32x16 cache lines in the main<br>
+ * surface. (As a corollary, each CCS tile corresponds to an area of<br>
+ * 32x16 tiles in the main surface.) This relationship holds regardless<br>
+ * of the size of the number of bits per pixel of the image format.<br>
+ *<br>
+ * In reality, the cache lines in the CCS tile are proportioned in an<br>
+ * 8B x 8 row configuration with each byte being 2x2 2-bit CCS entries.<br>
+ * However, CCS is documented as Y-tiled with the scaling relationship<br>
+ * described in terms of cache lines as above so we consider it to be<br>
+ * Y-tiled for the purpose of specifying this modifier. This means that<br>
+ * the row pitch for the CCS assumes 128B/tile.<br>
*/<br>
#define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)<br>
+<br>
+/* Reserved for the Yf version of the TILED_CCS modifier.<br>
+ *<br>
+ * Exact definition TBD.<br>
+ */<br>
#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)<br>
</blockquote>
<br></span>
Can we just rename this to RSVD, or does Mesa build already require this?<br></blockquote><div><br></div><div>Nothing requires it today. I'd be happy to just delete it TBH.</div><div><br></div><div>--Jason<br></div></div></div></div>