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

[Chris Wilson]

Quoting Pekka Paalanen (2017-09-27 15:25:21)
> On Wed, 27 Sep 2017 15:12:15 +0100
> Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 
> > 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.
> 
> Hi Chris,
> 
> do you mean that the timestamp from the sync fence itself is not any
> better than the user calling clock_gettime() the moment poll() says the
> fd is readable?

They are one and the same. The fd becomes readable a few instructions
after the timestamp is recorded. I was saying that if nobody was
listening, we didn't timestamp it.

> Why would the sync fence carry a timestamp at all then?
> 
> The very least I was expecting is that the GPU would record the
> timestamp which would then get converted to CLOCK_MONOTONIC in the
> kernel for reporting to userspace. Either that or zero.

Ah, no. The timestamp on the fence is purely cpu side. When a kernel thread
notices that the fence is complete, it then signals that fence (which
records the CLOCK_MONOTONIC timestamp and then wakes up all the listeners).

I'll pencil in recording the GPU timestamp just after switching from a
per-engine seqno timeline to a journal. (The key problem is at the
moment we don't see completion of individual fences, so don't have a
per-fence slot to store the timestamp either. Hmm. Actually...)
-Chris