public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>,
	Jani Nikula <jani.nikula@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [Intel-gfx] [PATCH v3 01/11] drm/i915: Add a table with a descriptor for all i915 modifiers
Date: Wed, 20 Oct 2021 13:50:48 +0300	[thread overview]
Message-ID: <YW/0iC1zuCFX5vPS@intel.com> (raw)
In-Reply-To: <20211020104630.GB1662819@ideak-desk.fi.intel.com>

On Wed, Oct 20, 2021 at 01:46:30PM +0300, Imre Deak wrote:
> On Wed, Oct 20, 2021 at 12:40:30PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 15, 2021 at 01:09:11AM +0300, Imre Deak wrote:
> > > +static const struct intel_modifier_desc intel_modifiers[] = {
> > > +	{
> > > +		.modifier = DRM_FORMAT_MOD_LINEAR,
> > > +		.display_ver = DISPLAY_VER_ALL,
> > > +
> > > +		.is_linear = true,
> > > +	},
> > > +	{
> > > +		.modifier = I915_FORMAT_MOD_X_TILED,
> > > +		.display_ver = DISPLAY_VER_ALL,
> > > +	},
> > > +	{
> > > +		.modifier = I915_FORMAT_MOD_Y_TILED,
> > > +		.display_ver = { 9, 13 },
> > > +	},
> > > +	{
> > > +		.modifier = I915_FORMAT_MOD_Yf_TILED,
> > > +		.display_ver = { 9, 11 },
> > > +	},
> > > +	{
> > > +		.modifier = I915_FORMAT_MOD_Y_TILED_CCS,
> > > +		.display_ver = { 9, 11 },
> > > +
> > > +		.ccs.type = INTEL_CCS_RC,
> > > +	},
> > > +	{
> > > +		.modifier = I915_FORMAT_MOD_Yf_TILED_CCS,
> > > +		.display_ver = { 9, 11 },
> > > +
> > > +		.ccs.type = INTEL_CCS_RC,
> > > +	},
> > > +	{
> > > +		.modifier = I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS,
> > > +		.display_ver = { 12, 13 },
> > > +
> > > +		.ccs.type = INTEL_CCS_RC,
> > > +	},
> > > +	{
> > > +		.modifier = I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC,
> > > +		.display_ver = { 12, 13 },
> > > +
> > > +		.ccs.type = INTEL_CCS_RC_CC,
> > > +	},
> > > +	{
> > > +		.modifier = I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS,
> > > +		.display_ver = { 12, 13 },
> > > +
> > > +		.ccs.type = INTEL_CCS_MC,
> > > +	},
> > > +};
> > > +
> > <snip>
> > > +u64 *intel_fb_plane_get_modifiers(struct drm_i915_private *i915,
> > > +				  enum intel_plane_caps plane_caps)
> > > +{
> > > +	u64 *list, *p;
> > > +	int count = 1;		/* +1 for invalid modifier terminator */
> > > +	int i;
> > > +
> > > +	for (i = 0; i < ARRAY_SIZE(intel_modifiers); i++) {
> > > +		if (plane_has_modifier(i915, plane_caps, &intel_modifiers[i]))
> > > +			count++;
> > > +	}
> > > +
> > > +	list = kmalloc_array(count, sizeof(*list), GFP_KERNEL);
> > > +	if (drm_WARN_ON(&i915->drm, !list))
> > > +		return NULL;
> > > +
> > > +	p = list;
> > > +	for (i = 0; i < ARRAY_SIZE(intel_modifiers); i++) {
> > > +		if (plane_has_modifier(i915, plane_caps, &intel_modifiers[i]))
> > > +			*p++ = intel_modifiers[i].modifier;
> > > +	}
> > > +	*p++ = DRM_FORMAT_MOD_INVALID;
> > 
> > Oh, one thing I just realized is that this will now list the modifiers
> > in the opposite order to what we had before. Previously we had roughly
> > compressed->tiled->linear order. I'm not sure sure anything relies on
> > that, but seems best to try and preserve it. I guess one could think
> > of it as some kind of priority order for the modifiers, where the more
> > efficient ones (in some sense) come first.
> 
> Hm, right that was subtle, thanks for catching it. 
> 
> As I understood Mesa (for instance) has to know what kind of modifiers
> it sees and do a priority reorder for other clients anyway (which don't
> know more about the mods besides the ID?).
> 
> +Danvet.
> 
> But the order shouldn't definitely be changed if there is no reason for
> it. Ensuring some priority order scheme already at the kernel i/f makes
> also sense to me. So if it's ok, I'll fix it up to be in the
> 
> gen12_mc -> gen12_rc -> gen12_rc_cc -> gen9_yf_rc -> gen9_y_rc -> yf_tiled -> y_tiled -> x_tiled -> linear
> 
> order, which is the current one.
> 
> For that matter, shouldn't gen12_rc_cc be before gen12_rc?

Probably. No idea why it's not currently.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2021-10-20 10:50 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14 22:09 [Intel-gfx] [PATCH v3 00/11] drm/i915: Simplify handling of modifiers Imre Deak
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 01/11] drm/i915: Add a table with a descriptor for all i915 modifiers Imre Deak
2021-10-15 18:04   ` Juha-Pekka Heikkila
2021-10-19  7:42     ` Jani Nikula
2021-10-19  7:46       ` Imre Deak
2021-10-20  9:40   ` Ville Syrjälä
2021-10-20 10:46     ` Imre Deak
2021-10-20 10:50       ` Ville Syrjälä [this message]
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 02/11] drm/i915: Move intel_get_format_info() to intel_fb.c Imre Deak
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 03/11] drm/i915: Add tiling attribute to the modifier descriptor Imre Deak
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 04/11] drm/i915: Simplify the modifier check for interlaced scanout support Imre Deak
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 05/11] drm/i915: Unexport is_semiplanar_uv_plane() Imre Deak
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 06/11] drm/i915: Move intel_format_info_is_yuv_semiplanar() to intel_fb.c Imre Deak
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 07/11] drm/i915: Add a platform independent way to get the RC CCS CC plane Imre Deak
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 08/11] drm/i915: Handle CCS CC planes separately from CCS AUX planes Imre Deak
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 09/11] drm/i915: Add a platform independent way to check for " Imre Deak
2021-10-19  8:02   ` Jani Nikula
2021-10-19  8:38     ` Imre Deak
2021-10-19  8:47       ` Imre Deak
2021-10-19 10:00         ` Imre Deak
2021-10-19  9:46   ` [Intel-gfx] [PATCH v4 " Imre Deak
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 10/11] drm/i915: Move is_ccs_modifier() to intel_fb.c Imre Deak
2021-10-14 22:09 ` [Intel-gfx] [PATCH v3 11/11] drm/i915: Add functions to check for RC CCS CC and MC CCS modifiers Imre Deak
2021-10-15  3:39 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Simplify handling of modifiers (rev10) Patchwork
2021-10-15  3:41 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-10-15  4:10 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-10-15 11:19 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-10-18 12:10   ` Imre Deak
2021-10-18 15:42     ` Petri Latvala
2021-10-18 16:10       ` Imre Deak
2021-10-19  7:41         ` Petri Latvala
2021-10-19 14:42 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Simplify handling of modifiers (rev11) Patchwork
2021-10-19 14:44 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-10-19 15:14 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-10-19 19:07 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=YW/0iC1zuCFX5vPS@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=juhapekka.heikkila@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox