From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: TIMESTAMP register Date: Mon, 30 Apr 2012 14:11:09 -0700 Message-ID: <87haw1apsi.fsf@eliezer.anholt.net> References: <36D38C1F74839847A52A484C31F3E51A154A0E59@IRSMSX101.ger.corp.intel.com> <20120417193943.GR4104@phenom.ffwll.local> <36D38C1F74839847A52A484C31F3E51A154A12B9@IRSMSX101.ger.corp.intel.com> <20120417210418.GS4104@phenom.ffwll.local> <20120417162745.229b7608@bwidawsk.net> <1334706720_15611@CP5-2952> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0006374990==" Return-path: In-Reply-To: <1334706720_15611@CP5-2952> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Chris Wilson , Ben Widawsky , Daniel Vetter Cc: "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org --===============0006374990== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable On Wed, 18 Apr 2012 00:51:42 +0100, Chris Wilson = wrote: > On Tue, 17 Apr 2012 16:27:45 -0700, Ben Widawsky wrote: > > On Tue, 17 Apr 2012 23:04:18 +0200 > > Daniel Vetter wrote: > >=20 > > > 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. > > >=20 > > > 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 > >=20 > > 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? >=20 > 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 I think you're referring to this: (11) Can the GL implementation use different clocks to implement the TIME_ELAPSED and TIMESTAMP queries? RESOLVED: Yes, the implemenation can use different internal clocks to implement TIME_ELAPSED and TIMESTAMP. If different clocks are used it is possible there is a slight discrepancy when comparing queries made from TIME_ELAPSED and TIMESTAMP; they may have slight differences when both are used to measure the same sequence. However, th= is is unlikely to affect real applications since comparing the two queries = is not expected to be useful. But that's about TIME_ELAPSED vs TIMESTAMP, not GPU-side TIMESTAMP vs CPU-side TIMESTAMP. Having those two not be the same clock seems crazy. Plus, as a bonus, if we get a general read-a-register ioctl, that means we could do a non-root gpu top. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk+e/+0ACgkQHUdvYGzw6vdqwwCgkw26XtRfpGf6F3qW5B4Z3rK/ E6kAnRphC6sBfZaHbRNGud+SwmOshQpf =THar -----END PGP SIGNATURE----- --=-=-=-- --===============0006374990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0006374990==--