All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] i915, drm/fourcc: Improve the CCS modifier documentation
@ 2017-08-18 18:34 Jason Ekstrand
  2017-08-18 19:24 ` ✓ Fi.CI.BAT: success for " Patchwork
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Jason Ekstrand @ 2017-08-18 18:34 UTC (permalink / raw)
  To: dri-devel, intel-gfx; +Cc: Jason Ekstrand, Ben Widawsky

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 <jason@jlekstrand.net>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 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.
+ */
 #define I915_FORMAT_MOD_Yf_TILED_CCS	fourcc_mod_code(INTEL, 5)
 
 /*
-- 
2.5.0.400.gff86faf

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

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* ✓ Fi.CI.BAT: success for i915, drm/fourcc: Improve the CCS modifier documentation
  2017-08-18 18:34 [PATCH] i915, drm/fourcc: Improve the CCS modifier documentation Jason Ekstrand
@ 2017-08-18 19:24 ` Patchwork
  2017-08-21 16:25 ` [PATCH] i915,drm/fourcc: " Ben Widawsky
  2017-08-25 15:10 ` [PATCH] i915, drm/fourcc: " Ville Syrjälä
  2 siblings, 0 replies; 6+ messages in thread
From: Patchwork @ 2017-08-18 19:24 UTC (permalink / raw)
  To: Jason Ekstrand; +Cc: intel-gfx

== Series Details ==

Series: i915, drm/fourcc: Improve the CCS modifier documentation
URL   : https://patchwork.freedesktop.org/series/29016/
State : success

== Summary ==

Series 29016v1 i915, drm/fourcc: Improve the CCS modifier documentation
https://patchwork.freedesktop.org/api/1.0/series/29016/revisions/1/mbox/

Test drv_module_reload:
        Subgroup basic-reload-inject:
                dmesg-warn -> PASS       (fi-kbl-7260u) fdo#102295

fdo#102295 https://bugs.freedesktop.org/show_bug.cgi?id=102295

fi-bdw-5557u     total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:453s
fi-bdw-gvtdvm    total:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  time:439s
fi-blb-e6850     total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  time:362s
fi-bsw-n3050     total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  time:554s
fi-bxt-j4205     total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:523s
fi-byt-j1900     total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  time:527s
fi-glk-2a        total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:625s
fi-hsw-4770      total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:444s
fi-hsw-4770r     total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:423s
fi-ilk-650       total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  time:421s
fi-ivb-3520m     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:512s
fi-ivb-3770      total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:479s
fi-kbl-7260u     total:279  pass:268  dwarn:1   dfail:0   fail:0   skip:10  time:502s
fi-kbl-7500u     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:483s
fi-kbl-7560u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:597s
fi-kbl-r         total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:592s
fi-pnv-d510      total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  time:537s
fi-skl-6260u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:468s
fi-skl-6700k     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:483s
fi-skl-6770hq    total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:490s
fi-skl-gvtdvm    total:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  time:436s
fi-skl-x1585l    total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:481s
fi-snb-2520m     total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  time:550s
fi-snb-2600      total:279  pass:249  dwarn:0   dfail:0   fail:1   skip:29  time:405s

ad6ab9f96437f0cb1f4d8a7840fd9eeb894eb12e drm-tip: 2017y-08m-18d-18h-21m-46s UTC integration manifest
dd46ad12e7b0 i915, drm/fourcc: Improve the CCS modifier documentation

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5444/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] i915,drm/fourcc: Improve the CCS modifier documentation
  2017-08-18 18:34 [PATCH] i915, drm/fourcc: Improve the CCS modifier documentation Jason Ekstrand
  2017-08-18 19:24 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2017-08-21 16:25 ` Ben Widawsky
  2017-08-21 23:20   ` Jason Ekstrand
  2017-08-25 15:10 ` [PATCH] i915, drm/fourcc: " Ville Syrjälä
  2 siblings, 1 reply; 6+ messages in thread
From: Ben Widawsky @ 2017-08-21 16:25 UTC (permalink / raw)
  To: Jason Ekstrand; +Cc: Jason Ekstrand, intel-gfx, dri-devel

On 17-08-18 11:34:40, 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 <jason@jlekstrand.net>
>Cc: Ben Widawsky <ben@bwidawsk.net>
>Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>---
> 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.

I guess if you're future proofing, you might want to bake in the language for
planar formats.

>+ *
>+ * 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.
>+ */
> #define I915_FORMAT_MOD_Yf_TILED_CCS	fourcc_mod_code(INTEL, 5)

Can we just rename this to RSVD, or does Mesa build already require this?

>
> /*
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] i915,drm/fourcc: Improve the CCS modifier documentation
  2017-08-21 16:25 ` [PATCH] i915,drm/fourcc: " Ben Widawsky
@ 2017-08-21 23:20   ` Jason Ekstrand
  0 siblings, 0 replies; 6+ messages in thread
From: Jason Ekstrand @ 2017-08-21 23:20 UTC (permalink / raw)
  To: Ben Widawsky; +Cc: Jason Ekstrand, Intel GFX, Maling list - DRI developers


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

On Mon, Aug 21, 2017 at 9:25 AM, Ben Widawsky <ben@bwidawsk.net> wrote:

> On 17-08-18 11:34:40, 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 <jason@jlekstrand.net>
>> Cc: Ben Widawsky <ben@bwidawsk.net>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> ---
>> 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.
>>
>
> I guess if you're future proofing, you might want to bake in the language
> for
> planar formats.
>

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..."


> + *
>> + * 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.
>> + */
>> #define I915_FORMAT_MOD_Yf_TILED_CCS    fourcc_mod_code(INTEL, 5)
>>
>
> Can we just rename this to RSVD, or does Mesa build already require this?
>

Nothing requires it today.  I'd be happy to just delete it TBH.

--Jason

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

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] i915, drm/fourcc: Improve the CCS modifier documentation
  2017-08-18 18:34 [PATCH] i915, drm/fourcc: Improve the CCS modifier documentation Jason Ekstrand
  2017-08-18 19:24 ` ✓ Fi.CI.BAT: success for " Patchwork
  2017-08-21 16:25 ` [PATCH] i915,drm/fourcc: " Ben Widawsky
@ 2017-08-25 15:10 ` Ville Syrjälä
  2017-08-25 22:50   ` Jason Ekstrand
  2 siblings, 1 reply; 6+ messages in thread
From: Ville Syrjälä @ 2017-08-25 15:10 UTC (permalink / raw)
  To: Jason Ekstrand; +Cc: Jason Ekstrand, intel-gfx, Ben Widawsky, dri-devel

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 <jason@jlekstrand.net>
> Cc: Ben Widawsky <ben@bwidawsk.net>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  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.
> + */

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.

>  #define I915_FORMAT_MOD_Yf_TILED_CCS	fourcc_mod_code(INTEL, 5)
>  
>  /*
> -- 
> 2.5.0.400.gff86faf

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] i915, drm/fourcc: Improve the CCS modifier documentation
  2017-08-25 15:10 ` [PATCH] i915, drm/fourcc: " Ville Syrjälä
@ 2017-08-25 22:50   ` Jason Ekstrand
  0 siblings, 0 replies; 6+ messages in thread
From: Jason Ekstrand @ 2017-08-25 22:50 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Jason Ekstrand, Intel GFX, Ben Widawsky, Maling list - DRI developers


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

On Fri, Aug 25, 2017 at 8:10 AM, Ville Syrjälä <
ville.syrjala@linux.intel.com> wrote:

> 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 <jason@jlekstrand.net>
> > Cc: Ben Widawsky <ben@bwidawsk.net>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  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.
> > + */
>
> 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.
>

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.

--Jason

[-- Attachment #1.2: Type: text/html, Size: 5966 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-08-25 22:50 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-18 18:34 [PATCH] i915, drm/fourcc: Improve the CCS modifier documentation Jason Ekstrand
2017-08-18 19:24 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-08-21 16:25 ` [PATCH] i915,drm/fourcc: " Ben Widawsky
2017-08-21 23:20   ` Jason Ekstrand
2017-08-25 15:10 ` [PATCH] i915, drm/fourcc: " Ville Syrjälä
2017-08-25 22:50   ` Jason Ekstrand

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.