On Wed, Mar 26, 2014 at 10:33 PM, Greg Hackmann ghackmann@google.com wrote:
On Wed, Mar 26, 2014 at 3:08 AM, Daniel Vetter daniel@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