[PATCH weston v3 4/4] gl-renderer: Emit GPU rendering begin and end timeline timepoints
ppaalanen at gmail.com
Thu Sep 28 08:37:50 UTC 2017
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
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:
These were requested by Mario Kleiner who runs some pretty demanding
Maybe that is over the top for fence timestamps, maybe not. Just a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel