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

[Daniel Vetter]

On Wed, Mar 26, 2014 at 10:33 PM, Greg Hackmann <ghackmann at google.com> wrote:
> 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.

Ah, thanks for the clarification, I was mixing up comments for ->set()
and ->prepare when reading the interface spec. So that wording sounds
like it's just to avoid resource leaks in case of a catastrophe so
that framebuffers frome older set calls get eventually reused. Makes
sense and with that I think we still can have useful compatibility
between Maarten's fences and android syncpoints.

I still see some fun with userspace potentially being required to
signal fences or fences created before the event is committed (e.g.
when using a buffer for scanout, which means it'll get used until it's
eventually replaced by something else). Just means there needs to be
some scheduler to keep things from stalling forever.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch