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

[Pekka Paalanen]

On Wed, 27 Sep 2017 15:53:23 +0100
Chris Wilson <chris at chris-wilson.co.uk> wrote:

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

Ok, thank you for the clarification, Chris. Appreciated.

(So that would actually allow us to sample the Weston event loop
responsiveness, hmm...)

I agree with the others that while your concerns are valid in general,
we should be just fine in this case.

I just wonder, there could probably be a way to communicate the
reliability of timestamps to userspace somehow. The reliability
qualifications came up when I was designing the Presentation feedback
Wayland protocol extension, which now has the following flags:
https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/presentation-time/presentation-time.xml?id=1.10#n157

These were requested by Mario Kleiner who runs some pretty demanding
applications.

Maybe that is over the top for fence timestamps, maybe not. Just a
thought.


Thanks,
pq
-------------- 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/20170928/bd5c2893/attachment.sig>