From: Ben Widawsky <ben@bwidawsk.net>
To: Rob Clark <rob@ti.com>
Cc: daniel.vetter@ffwll.ch, dri-devel@lists.freedesktop.org,
patches@linaro.org
Subject: Re: [RFC 0/9] nuclear pageflip
Date: Tue, 11 Sep 2012 14:15:14 -0700 [thread overview]
Message-ID: <20120911141514.4b291bee@bwidawsk.net> (raw)
In-Reply-To: <CAF6AEGti5G75d0BKLbvDVHWKAg-=M=0ipEtAGgWFkU2Qmd8tRQ@mail.gmail.com>
On Sun, 9 Sep 2012 22:19:59 -0500
Rob Clark <rob@ti.com> wrote:
> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark <rob.clark@linaro.org> wrote:
> > From: Rob Clark <rob@ti.com>
> >
> > This is following a bit the approach that Ville is taking for atomic-
> > modeset, in that it is switching over to using properties for everything.
> > The advantage of this approach is that it makes it easier to add new
> > attributes to set as part of a page-flip (and even opens the option to
> > add new object types).
>
> oh, and for those wondering what the hell this is all about,
> nuclear-pageflip is a pageflip that atomically updates the CRTC layer
> and zero or more attached plane layers, optionally changing various
> properties such as z-order (or even blending modes, etc) atomically.
> It includes the option for a test step so userspace compositor can
> test a proposed configuration (if any properties not marked as
> 'dynamic' are updated). This intended to allow, for example, weston
> compositor to synchronize updates to plane (sprite) layers with CRTC
> layer.
>
Can we please name this something different? I complained about this in
IRC, but I don't know if you hang around in #intel-gfx.
Some suggestions:
multiplane pageflip
muliplane atomic pageflip
atomic multiplane pageflip
atomic multiflip
pageflip of atomic and multiplane nature
Nuclear is not at all descriptive and requires as your response shows
:-)
> BR,
> -R
>
> > The basic principles are:
> > a) split out object state (in this case, plane and crtc, although I
> > expect more to be added as atomic-modeset is added) into seperate
> > structures that can be atomically commited or rolled back
> > b) expand the object property API (set_property()) to take a state
> > object. The obj->set_property() simply updates the state object
> > without actually applying the changes to the hw.
> > c) after all the property updates are done, the updated state can
> > be checked for correctness and against the hw capabilities, and
> > then either discarded or committed atomically.
> >
> > Since we need to include properties in the nuclear-pageflip scheme,
> > doing everything via properties avoids updating a bunch of additional
> > driver provided callbacks. Instead we just drop crtc->page_flip()
> > and plane->update_plane(). By splitting out the object's mutable
> > state into drm_{plane,crtc,etc}_state structs (which are wrapped by
> > the individual drivers to add their own hw specific state), we can
> > use some helpers (drm_{plane,crtc,etc}_set_property() and
> > drm_{plane,crtc,etc}_check_state()) to keep core error checking in
> > drm core and avoid pushing the burden of dealing with common
> > properties to the individual drivers.
> >
> > So far, I've only updated omapdrm to the new APIs, as a proof of
> > concept. Only a few drivers support drm plane, so I expect the
> > updates to convert drm-plane to properties should not be so hard.
> > Possibly for crtc/pageflip we might need to have a transition period
> > where we still support crtc->page_flip() code path until all drivers
> > are updated.
> >
> > My complete branch is here:
> >
> > https://github.com/robclark/kernel-omap4/commits/drm_nuclear
> > git://github.com/robclark/kernel-omap4.git drm_nuclear
> >
> > Rob Clark (9):
> > drm: add atomic fxns
> > drm: add object property type
> > drm: add DRM_MODE_PROP_DYNAMIC property flag
> > drm: convert plane to properties
> > drm: add drm_plane_state
> > drm: convert page_flip to properties
> > drm: add drm_crtc_state
> > drm: nuclear pageflip
> > drm/omap: update for atomic age
> >
> > drivers/gpu/drm/drm_crtc.c | 769 +++++++++++++++++++++++----------
> > drivers/gpu/drm/drm_crtc_helper.c | 51 +--
> > drivers/gpu/drm/drm_drv.c | 1 +
> > drivers/gpu/drm/drm_fb_helper.c | 11 +-
> > drivers/staging/omapdrm/Makefile | 1 +
> > drivers/staging/omapdrm/omap_atomic.c | 270 ++++++++++++
> > drivers/staging/omapdrm/omap_atomic.h | 52 +++
> > drivers/staging/omapdrm/omap_crtc.c | 247 +++++------
> > drivers/staging/omapdrm/omap_drv.c | 5 +
> > drivers/staging/omapdrm/omap_drv.h | 35 +-
> > drivers/staging/omapdrm/omap_fb.c | 44 +-
> > drivers/staging/omapdrm/omap_plane.c | 270 ++++++------
> > include/drm/drm.h | 2 +
> > include/drm/drmP.h | 32 ++
> > include/drm/drm_crtc.h | 140 ++++--
> > include/drm/drm_mode.h | 48 ++
> > 16 files changed, 1378 insertions(+), 600 deletions(-)
> > create mode 100644 drivers/staging/omapdrm/omap_atomic.c
> > create mode 100644 drivers/staging/omapdrm/omap_atomic.h
> >
> > --
> > 1.7.9.5
> >
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ben Widawsky, Intel Open Source Technology Center
next prev parent reply other threads:[~2012-09-11 21:15 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-10 3:03 [RFC 0/9] nuclear pageflip Rob Clark
2012-09-10 3:03 ` [RFC 1/9] drm: add atomic fxns Rob Clark
2012-09-12 16:57 ` Jesse Barnes
2012-09-12 17:35 ` Rob Clark
2012-09-12 18:03 ` Ville Syrjälä
2012-09-12 18:34 ` Rob Clark
2012-09-12 19:05 ` Jesse Barnes
2012-09-12 19:57 ` Rob Clark
2012-09-10 3:03 ` [RFC 2/9] drm: add object property type Rob Clark
2012-09-10 3:03 ` [RFC 3/9] drm: add DRM_MODE_PROP_DYNAMIC property flag Rob Clark
2012-09-10 3:03 ` [RFC 4/9] drm: convert plane to properties Rob Clark
2012-09-10 3:03 ` [RFC 5/9] drm: add drm_plane_state Rob Clark
2012-09-10 3:03 ` [RFC 6/9] drm: convert page_flip to properties Rob Clark
2012-09-10 3:03 ` [RFC 7/9] drm: add drm_crtc_state Rob Clark
2012-09-10 3:03 ` [RFC 8/9] drm: nuclear pageflip Rob Clark
2012-09-10 3:03 ` [RFC 9/9] drm/omap: update for atomic age Rob Clark
2012-09-10 3:19 ` [RFC 0/9] nuclear pageflip Rob Clark
2012-09-11 21:15 ` Ben Widawsky [this message]
2012-09-11 22:07 ` Rob Clark
2012-09-12 8:59 ` Ville Syrjälä
2012-09-12 12:30 ` Rob Clark
2012-09-12 14:23 ` Ville Syrjälä
2012-09-12 14:28 ` Rob Clark
2012-09-12 14:34 ` Ville Syrjälä
2012-09-12 14:42 ` Rob Clark
2012-09-12 15:12 ` Ville Syrjälä
2012-09-12 15:23 ` Rob Clark
2012-09-12 15:32 ` Ville Syrjälä
2012-09-12 15:48 ` Rob Clark
2012-09-12 17:27 ` Ville Syrjälä
2012-09-12 18:00 ` Clark, Rob
2012-09-12 18:58 ` Ville Syrjälä
2012-09-12 19:40 ` Rob Clark
2012-09-13 8:40 ` Ville Syrjälä
2012-09-13 13:39 ` Rob Clark
2012-09-13 14:29 ` Ville Syrjälä
2012-09-13 16:35 ` Rob Clark
2012-09-14 12:50 ` Ville Syrjälä
2012-09-14 13:25 ` Rob Clark
2012-09-14 13:58 ` Ville Syrjälä
2012-09-14 14:45 ` Rob Clark
2012-09-14 15:48 ` Ville Syrjälä
2012-09-14 16:29 ` Rob Clark
2012-09-14 17:02 ` Ville Syrjälä
2012-09-14 17:34 ` Rob Clark
2012-09-14 18:23 ` Ville Syrjälä
2012-09-14 21:51 ` Rob Clark
2012-09-15 2:12 ` Rob Clark
2012-09-15 14:56 ` Ville Syrjälä
2012-09-15 16:07 ` Rob Clark
2012-09-15 17:04 ` Ville Syrjälä
2012-09-15 17:15 ` Rob Clark
2012-09-15 19:08 ` Ville Syrjälä
2012-09-15 20:16 ` Rob Clark
2012-09-14 21:14 ` Jesse Barnes
2012-09-14 21:42 ` Rob Clark
2012-09-14 21:46 ` Kristian Høgsberg
2012-09-15 14:53 ` Ville Syrjälä
2012-09-15 16:05 ` Rob Clark
2012-09-15 18:00 ` Ville Syrjälä
2012-09-15 20:10 ` Rob Clark
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=20120911141514.4b291bee@bwidawsk.net \
--to=ben@bwidawsk.net \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=patches@linaro.org \
--cc=rob@ti.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.