All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: "Daniel Vetter" <daniel.vetter@intel.com>,
	"Marek Olšák" <maraeo@gmail.com>,
	"Juston Li" <juston.li@intel.com>,
	"Daniel Stone" <daniels@collabora.com>,
	"DRI Development" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/doc: Document that modifiers are always required for fb
Date: Wed, 2 Sep 2020 13:15:49 +0200	[thread overview]
Message-ID: <CAKMK7uHyX3_P_yK8=r9+XmeQcP3HcyMGNJNiJWAdHsRCQdCC+w@mail.gmail.com> (raw)
In-Reply-To: <20200902140238.51089b99@eldfell>

On Wed, Sep 2, 2020 at 1:02 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Wed,  2 Sep 2020 12:24:40 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> > Even for legacy userspace, since otherwise GETFB2 is broken and if you
> > switch between modifier-less and modifier-aware compositors, smooth
> > transitions break.
> >
> > Also it's just best practice to make sure modifiers are invariant for
> > a given drm_fb, and that a modifier-aware kms drivers only has one
> > place to store them, ignoring any old implicit bo flags or whatever
> > else might float around.
> >
> > Motivated by some irc discussion with Bas about amdgpu modifier
> > support.
> >
> > Fixes: 455e00f1412f ("drm: Add getfb2 ioctl")
> > Cc: Daniel Stone <daniels@collabora.com>
> > Cc: Juston Li <juston.li@intel.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
> > Cc: Marek Olšák <maraeo@gmail.com>
> > Cc: "Wentland, Harry" <harry.wentland@amd.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  include/drm/drm_mode_config.h | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > index a18f73eb3cf6..5ffbb4ed5b35 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -58,6 +58,12 @@ struct drm_mode_config_funcs {
> >        * actual modifier used if the request doesn't have it specified,
> >        * ie. when (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0.
> >        *
> > +      * IMPORTANT: These implied modifiers for legacy userspace must be
> > +      * stored in struct &drm_framebuffer, including all relevant metadata
> > +      * like &drm_framebuffer.pitches and &drm_framebuffer.offsets if the
> > +      * modifier enables additional planes beyond the fourcc pixel format
> > +      * code. This is required by the GETFB2 ioctl.
> > +      *
> >        * If the parameters are deemed valid and the backing storage objects in
> >        * the underlying memory manager all exist, then the driver allocates
> >        * a new &drm_framebuffer structure, subclassed to contain
> > @@ -915,6 +921,13 @@ struct drm_mode_config {
> >        * @allow_fb_modifiers:
> >        *
> >        * Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> > +      *
> > +      * IMPORTANT:
> > +      *
> > +      * If this is set the driver must fill out the full implicit modifier
> > +      * information in their &drm_mode_config_funcs.fb_create hook for legacy
> > +      * userspace which does not set modifiers. Otherwise the GETFB2 ioctl is
> > +      * broken for modifier aware userspace.
> >        */
> >       bool allow_fb_modifiers;
> >
>
> Hi,
>
> are there any drivers that would infer this information at
> modeset/pageflip/atomic ioctl time instead of AddFB/AddFB2 time?

Currently no, the only driver that infers anything for legacy is i915.
Proposed amdgpu modifier patches don't work like that, but I think Bas
is working on adding the modifier inference at addfb time for legacy
userspace.

> Userspace may be creating the FB once per buffer and keep re-using
> that over several render/display cycles. If a driver was changing the
> "effective modifiers" dynamically, userspace could break.

Yeah this is why I want to lock this all down, since effective
modifiers that change for a drm_fb object which is supposed to have
all invariant metadata just isn't great uapi.
-Daniel

>
>
> Thanks,
> pq



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-09-02 11:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 10:24 [PATCH] drm/doc: Document that modifiers are always required for fb Daniel Vetter
2020-09-02 11:02 ` Pekka Paalanen
2020-09-02 11:15   ` Daniel Vetter [this message]
2020-09-02 11:34     ` Pekka Paalanen
2020-09-02 12:40 ` Simon Ser
2020-09-02 12:44   ` Daniel Vetter
2020-09-02 12:49     ` Simon Ser
2020-09-02 12:56       ` Daniel Stone
2020-09-02 14:29       ` Bas Nieuwenhuizen
2020-09-02 14:29       ` Daniel Vetter
2020-09-02 14:59         ` Simon Ser
2020-09-07  8:31           ` Daniel Vetter
2020-09-07  8:37             ` Simon Ser
2020-09-07  8:41               ` Daniel Vetter
2020-09-07  9:07                 ` Pekka Paalanen
2020-09-07 13:51                   ` Daniel Vetter
2020-09-17 16:47 Daniel Vetter
2020-09-17 17:24 ` Bas Nieuwenhuizen
2020-09-23 15:53   ` Daniel Vetter

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='CAKMK7uHyX3_P_yK8=r9+XmeQcP3HcyMGNJNiJWAdHsRCQdCC+w@mail.gmail.com' \
    --to=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=juston.li@intel.com \
    --cc=maraeo@gmail.com \
    --cc=ppaalanen@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 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.