On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky <ben@xxxxxxxxxxxx> wrote:
> On Sun, 9 Sep 2012 22:19:59 -0500
> Rob Clark <rob@xxxxxx> wrote:
>
>> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote:
>> > From: Rob Clark <rob@xxxxxx>
>> >
>> > 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@xxxxxxxxxxxxxxxxxxxxx
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Ben Widawsky, Intel Open Source Technology Center
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
