[PATCH weston v3 4/4] gl-renderer: Emit GPU rendering begin and end timeline timepoints

[Chris Wilson]

Quoting Alexandros Frantzis (2017-09-27 15:01:08)
> On Wed, Sep 27, 2017 at 01:18:47PM +0100, Chris Wilson wrote:
> > Quoting Alexandros Frantzis (2017-09-27 13:09:16)
> > > Use EGL fence sync objects to emit timepoints for the beginning and the
> > > end of rendering on the GPU.
> > 
> > But why not use a qbo with GL_TIMESTAMP?
> > 
> > sync_file are only timestamped when they are signaled, which is very,
> > very loosely coupled with the GPU rendering. Each will also force a
> > flush and submission of the GL pipeline, which seems to me to be very
> > heavyweight ?
> > -Chris
> 
> Hi Chris,
> 
> using GL timestamp queries was my initial approach for implementing this
> feature. However, Mesa currently lacks support for the
> EGL_EXT_disjoint_timer_query extension so this approach was abandoned
> (for now, at least) in favor of EGLSyncKHR + sync files.

Please do include what approaches you tried and why sync_files are
preferred in the changelog, or comments. That background helps :)
 
> Furthermore, sync files have the advantage that they can be easily
> integrated with the event loop.  Query objects would lead to a more
> complex flow since they require explicit polling for readiness.
> 
> My impression is that the sync file timestamps were "close enough" for
> the intended purpose here. Another (minor) point is that the sync file
> timestamps are in a clock domain (CLOCK_MONOTONIC) we can use directly
> for correlation with compositor and other system events.

I can only promise you that the timestamp is less than 2s since the
event. (Hmm, and I really can't make that a very strong promise ;)
We don't signal the fence unless there is a listener. Adding the
sync_file to the event loop will add that listener, so the delay between
creating the sync_file and poll() will be the upper error bound.
 
> Finally, concerning the heaviness of the sync fence flushes, I don't
> think any performance effects are significant enough to be a cause for
> concern for our use case (but I guess it all depends on driver and GPU
> details).

That's your call, I was just concerned that it is a large perturbation on
the GL pipeline, changing the behaviour of the system you wanted to
measure.
-Chris