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

[Pekka Paalanen]

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?

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.


Thanks,
pq

> > 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170927/718b5adb/attachment.sig>