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
next prev parent 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