[RFC 0/4] Atomic Display Framework

[Greg Hackmann]

On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrjälä <
ville.syrjala at linux.intel.com> wrote:

> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann <ghackmann at google.com>
> wrote:
>
> > 1.  The API is geared toward updating one object at a time.  Android's
> graphics stack needs the entire screen updated atomically to avoid tearing,
> and on some SoCs to avoid wedging the display hardware.  Rob Clark's atomic
> modeset patchset worked, but copy/update/commit design meant the driver had
> to keep a lot more internal state.
> > >
> >
> > I'm not entirely sure how to avoid that, because at least some hw we
> > need to have the entire new-state in order to validate if it is
> > possible.
>
> I guess the only reason adf is a bit different is that there can only be
> one custom (driver specific!) blob in the ioctl, so the driver is just
> free to dump that directly into whatever internal structure it uses to
> store the full state. So it just frees you from the per-prop state
> buildup process.
>

Right, the difference is that clients send the complete state they want
rather than deltas against the current state.  This means the driver
doesn't have to track its current state and duplicate it at the beginning
of the flip operation, which is a minor pain on hardware with a ton of
knobs to twist across different hardware blocks.

Maybe the important question is whether incremental atomic updates is a
use-case that clients need in practice.  SurfaceFlinger tells the HW
composer each frame "here's a complete description of what I want onscreen,
make it so" and IIRC Weston works the same way.

I used a blob rather than property/value pairs because the composition is
going to be inherently device specific anyway.  Display controllers have
such different features and constraints that you'd end up with each driver
exposing a bunch of hardware-specific properties, and I'm not convinced
that's any better than just letting the driver dictate how the requests are
structured (modulo a handful of hardware-agnostic properties).  I'm not
strongly tied to blobs over properties but I think the former's easier on
driver developers.


> But if the idea would to be totally driver specific anyway, I wouldn't
> even bother with any of this fancy framework stuff. Just specify some
> massive driver specific structure with a custom ioctl and call it a
> day.
>

I disagree -- this is basically what vendors do today to support Android,
and there's a lot of common scaffolding that could go into a framework.
 The custom ioctl handlers all look reasonably close to this:

1) import dma-bufs and fences from their respective fds
2) map the buffers into the display device
3) validate the buffer sizes against their formats and width/stride/height
4) validate the requested layout doesn't violate hardware constraints
5) hand everything off to a worker that waits for the buffers' sync fences
to fire
6) commit the requested layout to hardware
7) unmap and release all the buffers that just left the screen
8) advance the sync timeline

with some leeway on the ordering of (2)-(4) and (7)-(8).  ADF handles all
of this except for (4) and (6), which are inherently hardware-specific and
delegated to driver ops.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130829/40a64085/attachment.html>