[RFC 0/9] nuclear pageflip

[Rob Clark]

On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
> On Sun, 9 Sep 2012 22:19:59 -0500
> Rob Clark <rob at ti.com> wrote:
>
>> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark <rob.clark at linaro.org> wrote:
>> > From: Rob Clark <rob at 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
> :-)
>

fair enough.. I was originally calling it atomic-pageflip until
someone (I don't remember who) started calling it nuclear-pageflip to
differentiate from atomic-modeset.  But IMO we could just call the two
ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
pageflip2, but that seems much more boring)

BR,
-R

>
>> 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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Ben Widawsky, Intel Open Source Technology Center
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel