On Wed, Mar 26, 2014 at 10:33 PM, Greg Hackmann <ghackmann@xxxxxxxxxx> wrote: > 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. 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
