On Wed, Mar 26, 2014 at 3:08 AM, Daniel Vetter <daniel@xxxxxxxx> 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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
