Re: TIMESTAMP register

[Chris Wilson <chris@chris-wilson.co.uk>]

On Tue, 17 Apr 2012 16:27:45 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> On Tue, 17 Apr 2012 23:04:18 +0200
> Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Tue, Apr 17, 2012 at 08:34:11PM +0000, Lawrynowicz, Jacek wrote:
> > > ARB_timer_query allows client read TIMESTAMP both asynchronously and synchronously.
> > > The former can be implemented as you said but the latter requires support from the KMD.
> > > This must be a simple MMIO read as this is the only way to report "current" GPU time.
> > > Implementing synchronous TIMESTAMP query using pipe control would render the third example from ARB_timer_query spec useless.
> > 
> > Ok, I've looked like a dofus again, but now I've read the spec and we
> > indeed seem to need a synchronous readout of the TIMESTAMP register. I
> > guess a new register will do, together with some fixed-point integer that
> > tells userspace how to convert it to nanoseconds.
> > -Daniel
> 
> I've not read the spec, but synchronous and "current" doesn't mean the
> exact same thing to me. I assume the spec doesn't allow getting the
> value in a batch and then just waiting for rendering to complete?

The spec stipulates that the client is able to query the timestamp
counter synchronously from within the render stream (ala PIPE_CONTROL)
and query the current timestamp asynchronously. The spec also explicitly
allows for those two clocks to be different (though close enough for the
user to not care). Therefore you need only use the nanosecond monotonic
clock for the asynchronous query and apply an offset to the GPU timestamp
when converting that from ticks to nanoseconds. My bet is that
clock_gettime() is going to beat even ioctl(QUERY_COUNTER), not least
because TIMESTAMP (being a per-ring register) is going to require
the forcewake dance.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre