From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org,
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 1/2] drm: Add drm_any_plane_has_format()
Date: Tue, 30 Oct 2018 16:18:28 +0200 [thread overview]
Message-ID: <20181030141828.GY9144@intel.com> (raw)
In-Reply-To: <20181030093507.GO21967@phenom.ffwll.local>
On Tue, Oct 30, 2018 at 10:35:07AM +0100, Daniel Vetter wrote:
> On Mon, Oct 29, 2018 at 04:00:04PM -0700, Eric Anholt wrote:
> > Ville Syrjala <ville.syrjala@linux.intel.com> writes:
> >
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > Add a function to check whether there is at least one plane that
> > > supports a specific format and modifier combination. Drivers can
> > > use this to reject unsupported formats/modifiers in .fb_create().
> > >
> > > v2: Accept anyformat if the driver doesn't do planes (Eric)
> > > s/planes_have_format/any_plane_has_format/ (Eric)
> > > Check the modifier as well since we already have a function
> > > that does both
> > > v3: Don't do the check in the core since we may not know the
> > > modifier yet, instead export the function and let drivers
> > > call it themselves
> > >
> > > Cc: Eric Anholt <eric@anholt.net>
> > > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> >
> > I don't particularly see the point in having FB creation duplicate the
> > validation that atomic check will eventually do, and it means that FB
> > creation cost scales with plane count, but if i915's going to do this,
> > it seems reasonable for them.
>
> atomic_check checks for a given plane only, I do think it makes sense to
> make sure you can't create framebuffers that are impossible to use on a
> given driver at addfb time.
>
> In case the overhead is ever critical, we could compile a static map of
> this at driver load time, and then check that.
>
> Aside: Shouldn't we make this the default for atomic drivers? With
> atomic drivers we can assume that all planes have valid format lists
> (because atomic_check checks them already). Only with non-atomic drivers,
> how might have a faked primary plane is this not a valid assumption ...
The problem of making this automagic for everyone was the
legacy tiling->modifier thing.
https://patchwork.freedesktop.org/patch/210193/ +
https://patchwork.freedesktop.org/patch/208070/
is the best I could really come up with when I tried to make this
entirely automagic. I haven't bothered to revisit those because I
wasn't entirely happy with needing the extra vfunc, and people
didn't seem too excited about this idea.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-10-30 14:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 18:34 [PATCH v4 1/2] drm: Add drm_any_plane_has_format() Ville Syrjala
2018-10-29 18:34 ` [PATCH v4 2/2] drm/i915: Eliminate the horrendous format check code Ville Syrjala
2018-10-29 19:23 ` Dhinakaran Pandiyan
2018-10-29 20:48 ` ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm: Add drm_any_plane_has_format() Patchwork
2018-10-29 23:00 ` [PATCH v4 1/2] " Eric Anholt
2018-10-30 9:35 ` Daniel Vetter
2018-10-30 14:18 ` Ville Syrjälä [this message]
2018-10-30 15:35 ` Daniel Vetter
2018-10-30 1:48 ` ✓ Fi.CI.IGT: success for series starting with [v4,1/2] " 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=20181030141828.GY9144@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=dhinakaran.pandiyan@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/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.