[PATCH 00/16] Atomic/nuclear modeset/pageflip
Daniel Vetter
daniel at ffwll.ch
Wed Mar 26 15:33:27 PDT 2014
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
More information about the dri-devel
mailing list