All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chery, Nanley G" <nanley.g.chery@intel.com>
To: "Sripada, Radhakrishna" <radhakrishna.sripada@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "Syrjala, Ville" <ville.syrjala@intel.com>,
	"Ekstrand, Jason" <jason.ekstrand@intel.com>,
	"Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Subject: Re: [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color
Date: Wed, 30 Oct 2019 00:05:13 +0000	[thread overview]
Message-ID: <8B74F386D1656545A7968FB3C487BECC2B6F3C52@ORSMSX116.amr.corp.intel.com> (raw)
In-Reply-To: <20191028204041.13507-10-radhakrishna.sripada@intel.com>

+Jason 

Maybe Jason and/or others have some thoughts on the following? Given the
detailed description of the clear color struct, it seems like we'll have to
define a new modifier if the struct fields change in a future generation.

On negative is that we might have to make new modifiers that provide no
additional benefit (assuming the new/changed fields are unused). On positive is
that it's probably a good thing that we mentioned the Raw clear color fields
because I think 3D uses it during rendering operations and we'll be sharing
from 3D-to-3D. Maybe we should specify how the channels should be formatted? 

I haven't thought through how fields like Color Discard Enable affect buffer
sharing...

Another comment: I noticed that none of the Y+CCS modifiers explicitly state
that the CCS must be in the same BO as the Y-tiled main surface. We should at
least fix that for newly defined modifiers right?

-Nanley

> ________________________________________
> From: Sripada, Radhakrishna
> Sent: Monday, October 28, 2019 1:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Pandiyan, Dhinakaran; Syrjala, Ville; Sharma, Shashank; Antognolli, Rafael; Chery, Nanley G; Sripada, Radhakrishna; Ville Syrjala; Kondapally, Kalyan
> Subject: [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color
> 
> Gen12 display can decompress surfaces compressed by render engine with
> Clear Color, add a new modifier as the driver needs to know the surface
> was compressed by render engine.
> 
> V2: Description changes as suggested by Rafael.
> V3: Mention the Clear Color size of 64 bits in the comments(DK)
> v4: Fix trailing whitespaces
> v5: Explain Clear Color in the documentation.
> v6: Documentation Nitpicks(Nanley)
> 
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> Cc: Kalyan Kondapally <kalyan.kondapally@intel.com>
> Cc: Rafael Antognolli <rafael.antognolli@intel.com>
> Cc: Nanley Chery <nanley.g.chery@intel.com>
> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> ---
>  include/uapi/drm/drm_fourcc.h | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 1aa6d468c048..4aa7f3f9712a 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -434,6 +434,25 @@ extern "C" {
>   */
>  #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
> 
> +/*
> + * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
> + * compression.
> + *
> + * The main surface is Y-tiled and is at plane index 0 whereas CCS is linear
> + * and at index 1. The clear color is stored at index 2, and the pitch should
> + * be ignored. The clear color structure is 256 bits. The first 128 bits
> + * represents Raw Clear Color Red, Green, Blue and Alpha color each represented
> + * by 32 bits. The raw clear color is consumed by the 3d engine and generates
> + * the converted clear color of size 64 bits. The first 32 bits store the Lower
> + * Converted Clear Color value and the next 32 bits store the Higher Converted
> + * Clear Color value when applicable. The Converted Clear Color values are
> + * consumed by the DE. The last 64 bits are used to store Color Discard Enable
> + * and Depth Clear Value Valid which are ignored by the DE. A CCS cache line
> + * corresponds to an area of 4x1 tiles in the main surface. The main surface
> + * pitch is required to be a multiple of 4 tile widths.
> + */
> +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
> +
>  /*
>   * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
>   *
> --
> 2.20.1
> 
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: "Chery, Nanley G" <nanley.g.chery@intel.com>
To: "Sripada, Radhakrishna" <radhakrishna.sripada@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "Syrjala, Ville" <ville.syrjala@intel.com>,
	"Ekstrand, Jason" <jason.ekstrand@intel.com>,
	"Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Subject: Re: [Intel-gfx] [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color
Date: Wed, 30 Oct 2019 00:05:13 +0000	[thread overview]
Message-ID: <8B74F386D1656545A7968FB3C487BECC2B6F3C52@ORSMSX116.amr.corp.intel.com> (raw)
Message-ID: <20191030000513.o53QTkk-QCOQBxZzsxkUYX4m1h-CgjKie-wQSbaMRpg@z> (raw)
In-Reply-To: <20191028204041.13507-10-radhakrishna.sripada@intel.com>

+Jason 

Maybe Jason and/or others have some thoughts on the following? Given the
detailed description of the clear color struct, it seems like we'll have to
define a new modifier if the struct fields change in a future generation.

On negative is that we might have to make new modifiers that provide no
additional benefit (assuming the new/changed fields are unused). On positive is
that it's probably a good thing that we mentioned the Raw clear color fields
because I think 3D uses it during rendering operations and we'll be sharing
from 3D-to-3D. Maybe we should specify how the channels should be formatted? 

I haven't thought through how fields like Color Discard Enable affect buffer
sharing...

Another comment: I noticed that none of the Y+CCS modifiers explicitly state
that the CCS must be in the same BO as the Y-tiled main surface. We should at
least fix that for newly defined modifiers right?

-Nanley

> ________________________________________
> From: Sripada, Radhakrishna
> Sent: Monday, October 28, 2019 1:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Pandiyan, Dhinakaran; Syrjala, Ville; Sharma, Shashank; Antognolli, Rafael; Chery, Nanley G; Sripada, Radhakrishna; Ville Syrjala; Kondapally, Kalyan
> Subject: [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color
> 
> Gen12 display can decompress surfaces compressed by render engine with
> Clear Color, add a new modifier as the driver needs to know the surface
> was compressed by render engine.
> 
> V2: Description changes as suggested by Rafael.
> V3: Mention the Clear Color size of 64 bits in the comments(DK)
> v4: Fix trailing whitespaces
> v5: Explain Clear Color in the documentation.
> v6: Documentation Nitpicks(Nanley)
> 
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> Cc: Kalyan Kondapally <kalyan.kondapally@intel.com>
> Cc: Rafael Antognolli <rafael.antognolli@intel.com>
> Cc: Nanley Chery <nanley.g.chery@intel.com>
> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> ---
>  include/uapi/drm/drm_fourcc.h | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 1aa6d468c048..4aa7f3f9712a 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -434,6 +434,25 @@ extern "C" {
>   */
>  #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
> 
> +/*
> + * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
> + * compression.
> + *
> + * The main surface is Y-tiled and is at plane index 0 whereas CCS is linear
> + * and at index 1. The clear color is stored at index 2, and the pitch should
> + * be ignored. The clear color structure is 256 bits. The first 128 bits
> + * represents Raw Clear Color Red, Green, Blue and Alpha color each represented
> + * by 32 bits. The raw clear color is consumed by the 3d engine and generates
> + * the converted clear color of size 64 bits. The first 32 bits store the Lower
> + * Converted Clear Color value and the next 32 bits store the Higher Converted
> + * Clear Color value when applicable. The Converted Clear Color values are
> + * consumed by the DE. The last 64 bits are used to store Color Discard Enable
> + * and Depth Clear Value Valid which are ignored by the DE. A CCS cache line
> + * corresponds to an area of 4x1 tiles in the main surface. The main surface
> + * pitch is required to be a multiple of 4 tile widths.
> + */
> +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
> +
>  /*
>   * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
>   *
> --
> 2.20.1
> 
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-10-30  0:05 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-28 20:40 [PATCH v6 00/10] Clear Color Support for TGL Render Decompression Radhakrishna Sripada
2019-10-28 20:40 ` [Intel-gfx] " Radhakrishna Sripada
2019-10-28 20:40 ` [PATCH v6 01/10] drm/framebuffer: Format modifier for Intel Gen-12 render compression Radhakrishna Sripada
2019-10-28 20:40   ` [Intel-gfx] " Radhakrishna Sripada
2019-10-28 20:40 ` [PATCH v6 02/10] drm/i915: Use intel_tile_height() instead of re-implementing Radhakrishna Sripada
2019-10-28 20:40   ` [Intel-gfx] " Radhakrishna Sripada
2019-10-28 20:40 ` [PATCH v6 03/10] drm/i915: Move CCS stride alignment W/A inside intel_fb_stride_alignment Radhakrishna Sripada
2019-10-28 20:40   ` [Intel-gfx] " Radhakrishna Sripada
2019-10-28 20:40 ` [PATCH v6 04/10] drm/i915/tgl: Gen-12 render decompression Radhakrishna Sripada
2019-10-28 20:40   ` [Intel-gfx] " Radhakrishna Sripada
2019-10-28 20:40 ` [PATCH v6 05/10] drm/i915: Extract framebufer CCS offset checks into a function Radhakrishna Sripada
2019-10-28 20:40   ` [Intel-gfx] " Radhakrishna Sripada
2019-10-28 20:40 ` [PATCH v6 06/10] drm/framebuffer: Format modifier for Intel Gen-12 media compression Radhakrishna Sripada
2019-10-28 20:40   ` [Intel-gfx] " Radhakrishna Sripada
2019-10-28 20:40 ` [PATCH v6 07/10] drm/fb: Extend format_info member arrays to handle four planes Radhakrishna Sripada
2019-10-28 20:40   ` [Intel-gfx] " Radhakrishna Sripada
2019-10-28 20:40 ` [PATCH v6 08/10] Gen-12 display can decompress surfaces compressed by the media engine Radhakrishna Sripada
2019-10-28 20:40   ` [Intel-gfx] " Radhakrishna Sripada
2019-10-28 20:40 ` [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color Radhakrishna Sripada
2019-10-28 20:40   ` [Intel-gfx] " Radhakrishna Sripada
2019-10-30  0:05   ` Chery, Nanley G [this message]
2019-10-30  0:05     ` Chery, Nanley G
2019-11-01  7:00     ` Sripada, Radhakrishna
2019-11-01  7:00       ` [Intel-gfx] " Sripada, Radhakrishna
2019-11-12 17:40       ` Chery, Nanley G
2019-11-12 17:40         ` [Intel-gfx] " Chery, Nanley G
2019-11-13 22:33         ` Chery, Nanley G
2019-11-13 22:33           ` [Intel-gfx] " Chery, Nanley G
2019-10-28 20:40 ` [PATCH v6 10/10] drm/i915/tgl: Add Clear Color support for TGL Render Decompression Radhakrishna Sripada
2019-10-28 20:40   ` [Intel-gfx] " Radhakrishna Sripada
2019-10-29  0:02 ` ✗ Fi.CI.CHECKPATCH: warning for Clear Color Support for TGL Render Decompression (rev9) Patchwork
2019-10-29  0:02   ` [Intel-gfx] " Patchwork
2019-10-29  0:49 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-10-29  0:49   ` [Intel-gfx] " 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=8B74F386D1656545A7968FB3C487BECC2B6F3C52@ORSMSX116.amr.corp.intel.com \
    --to=nanley.g.chery@intel.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jason.ekstrand@intel.com \
    --cc=radhakrishna.sripada@intel.com \
    --cc=ville.syrjala@intel.com \
    /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 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.