Quoting Pekka Paalanen (2017-09-27 15:25:21) > On Wed, 27 Sep 2017 15:12:15 +0100 > Chris Wilson <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
