[PATCH 00/16] Atomic/nuclear modeset/pageflip

[Greg Hackmann]

On Wed, Mar 26, 2014 at 3:08 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>
> - You have an explicit callback for vblank events (well, just the
>   interrupt, afaics no support to get a vblank event for a specific frame
>   in the future). Any reason not to use android syncpoint fences for this
>   like everywhere else? Or is the idea behind all the fences hwc throws
>   around just to synchronize read/write access from
>   cpu/render/codec/whatever and not so much timing?
>

Vsync events are used to kick off Android's rendering loop.  The upshot is
that when SurfaceFlinger requests vsync events from the HWC HAL, it needs
to deliver them at every vsync even if the display hasn't changed.

Fences tell a consumer when the producer's done with the buffer, and aren't
really meant for timing.  (Or probably even useful for timing, since they
don't pass along any timestamping information about when the event
happened.)

- If I read this correct you mandate that the fences fields gets filled
>   out in the prepare hook, i.e. before we commit the new state to
>   hardware. You also mandate that the fences get eventually signalled even
>   when surfaceflinger decides to not commit the new state.
>

The HWC HAL needs to fill in the release fences during set().  The mandate
w.r.t. fences is that if SurfaceFlinger calls

prepare(A)
set(A)
prepare(B)
set(B)

and something inside set(B) fails for some reason, the HWC HAL must ensure
that the fences returned by set(A) eventually fire anyway.  That situation
really shouldn't happen unless something goes horribly wrong, since the
expectation is that prepare(B) will pick a composition that set(B) can
display.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/57872928/attachment.html>