<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 26, 2014 at 3:08 AM, Daniel Vetter <span dir="ltr"><<a href="mailto:daniel@ffwll.ch" target="_blank">daniel@ffwll.ch</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">




- You have an explicit callback for vblank events (well, just the<br>
  interrupt, afaics no support to get a vblank event for a specific frame<br>
  in the future). Any reason not to use android syncpoint fences for this<br>
  like everywhere else? Or is the idea behind all the fences hwc throws<br>
  around just to synchronize read/write access from<br>
  cpu/render/codec/whatever and not so much timing?<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div>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.)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


- If I read this correct you mandate that the fences fields gets filled<br>
  out in the prepare hook, i.e. before we commit the new state to<br>
  hardware. You also mandate that the fences get eventually signalled even<br>
  when surfaceflinger decides to not commit the new state.<br></blockquote><div><br></div><div>The HWC HAL needs to fill in the release fences during set().  The mandate w.r.t. fences is that if SurfaceFlinger calls</div>
<div>
<br></div><div>prepare(A)</div><div>set(A)</div><div>prepare(B)</div><div>set(B)</div><div><br></div><div>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.</div>


</div></div></div>