TIMESTAMP register

TIMESTAMP register

[Lawrynowicz, Jacek]

[-- Attachment #1.1.1: Type: text/plain, Size: 445 bytes --]

Hi,

 

Starting from IVB the main TIMESTAMP register is longer than 32 bits (it’s 36 bits long).

How should we pass its 36 bit value from i915 to user space?

GET_PARAM ioctls supports only 32 bit params. Should we add GET_PARAM64 or create separate ioctl to access the TIMESTAMP?

Any suggestions?

 

This functionality is required for any OpenGL driver which implements GL_ARB_timer_query.

 

Regards,

Jacek

 


[-- Attachment #1.1.2: Type: text/html, Size: 2629 bytes --]

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 8658 bytes --]

[-- Attachment #2: Type: text/plain, Size: 599 bytes --]

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: TIMESTAMP register

[Daniel Vetter]

On Tue, Apr 17, 2012 at 07:12:40PM +0000, Lawrynowicz, Jacek wrote:
> Starting from IVB the main TIMESTAMP register is longer than 32 bits
> (it’s 36 bits long).
> 
> How should we pass its 36 bit value from i915 to user space?
> 
> GET_PARAM ioctls supports only 32 bit params. Should we add GET_PARAM64
> or create separate ioctl to access the TIMESTAMP?
> 
> Any suggestions?
> 
>  
> 
> This functionality is required for any OpenGL driver which implements GL_ARB_timer_query.

Like occlusion queries I presume this should be done with a pipe control
qword write issued from a batch. GETPARAM makes absolutely no sense, that
is for driver features, not hw features and just used so that a new driver
also can work on an older kernel.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: TIMESTAMP register

[Lawrynowicz, Jacek]

[-- Attachment #1.1: Type: text/plain, Size: 1504 bytes --]

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.

Regards,
Jacek

-----Original Message-----
From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, April 17, 2012 9:40 PM
To: Lawrynowicz, Jacek
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] TIMESTAMP register

On Tue, Apr 17, 2012 at 07:12:40PM +0000, Lawrynowicz, Jacek wrote:
> Starting from IVB the main TIMESTAMP register is longer than 32 bits 
> (it’s 36 bits long).
> 
> How should we pass its 36 bit value from i915 to user space?
> 
> GET_PARAM ioctls supports only 32 bit params. Should we add 
> GET_PARAM64 or create separate ioctl to access the TIMESTAMP?
> 
> Any suggestions?
> 
>  
> 
> This functionality is required for any OpenGL driver which implements GL_ARB_timer_query.

Like occlusion queries I presume this should be done with a pipe control qword write issued from a batch. GETPARAM makes absolutely no sense, that is for driver features, not hw features and just used so that a new driver also can work on an older kernel.

-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 8658 bytes --]

[-- Attachment #2: Type: text/plain, Size: 599 bytes --]

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: TIMESTAMP register

[Daniel Vetter]

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
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: TIMESTAMP register

[Ben Widawsky]

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?

If we go with the register read approach, I vote sysfs.

Re: TIMESTAMP register

[Chris Wilson]

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

Re: TIMESTAMP register

[Lawrynowicz, Jacek]

[-- Attachment #1.1: Type: text/plain, Size: 2811 bytes --]

I think that ioctl to get GPU timestamp and its resolution would be the best 
approach.
This ioctl won't be called very often so there's no need to sacrifice 
simplicity for performance in this case.
Using clock_gettime() sounds like trouble to me.
How would you keep GPU and CPU time synchronized?
Is forcewakeup necessary in case of a register which is not affected by gfx 
reset?

Regards,
Jacek

-----Original Message-----
From: intel-gfx-bounces+jacek.lawrynowicz=intel.com@lists.freedesktop.org 
[mailto:intel-gfx-bounces+jacek.lawrynowicz=intel.com@lists.freedesktop.org] 
On Behalf Of Chris Wilson
Sent: Wednesday, April 18, 2012 1:52 AM
To: Ben Widawsky; Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] TIMESTAMP register

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 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 8658 bytes --]

[-- Attachment #2: Type: text/plain, Size: 599 bytes --]

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: TIMESTAMP register

[Chris Wilson]

On Wed, 18 Apr 2012 06:32:04 +0000, "Lawrynowicz, Jacek" <jacek.lawrynowicz@intel.com> wrote:
> I think that ioctl to get GPU timestamp and its resolution would be the best 
> approach.
> This ioctl won't be called very often so there's no need to sacrifice 
> simplicity for performance in this case.
> Using clock_gettime() sounds like trouble to me.
> How would you keep GPU and CPU time synchronized?
The bspec explicitly says that the GPU timestamp is adjusted for changes
in render frequency so that it is consistent. Similarly CLOCK_MONOTONIC.

> Is forcewakeup necessary in case of a register which is not affected by gfx 
> reset?

They are in the GT powerwell, so yes forcewake will be necessary for the
read not to return garbage.

The rule of thumb is to keep interfaces out of the kernel unless there
is a compelling reason otherwise. I think there is a good reason for a
ioctl(QUERY_COUNTER), but I can also see that you can implement
proof-of-principle code for this ARB timer entirely in userspace.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: TIMESTAMP register

[Lawrynowicz, Jacek]

[-- Attachment #1.1: Type: text/plain, Size: 1588 bytes --]

But how would I synchronize GPU and CPU clocks without access to the TIMESTAMP 
register?
And are you sure that over time both clocks won't desynchronize?

Do you all agree that this functionality should not be implemented in the 
kernel?

Regards,
Jacek

-----Original Message-----
From: Chris Wilson [mailto:chris@chris-wilson.co.uk]
Sent: Wednesday, April 18, 2012 9:36 AM
To: Lawrynowicz, Jacek; Ben Widawsky; Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] TIMESTAMP register

On Wed, 18 Apr 2012 06:32:04 +0000, "Lawrynowicz, Jacek" 
<jacek.lawrynowicz@intel.com> wrote:
> I think that ioctl to get GPU timestamp and its resolution would be
> the best approach.
> This ioctl won't be called very often so there's no need to sacrifice
> simplicity for performance in this case.
> Using clock_gettime() sounds like trouble to me.
> How would you keep GPU and CPU time synchronized?
The bspec explicitly says that the GPU timestamp is adjusted for changes in 
render frequency so that it is consistent. Similarly CLOCK_MONOTONIC.

> Is forcewakeup necessary in case of a register which is not affected
> by gfx reset?

They are in the GT powerwell, so yes forcewake will be necessary for the read 
not to return garbage.

The rule of thumb is to keep interfaces out of the kernel unless there is a 
compelling reason otherwise. I think there is a good reason for a 
ioctl(QUERY_COUNTER), but I can also see that you can implement 
proof-of-principle code for this ARB timer entirely in userspace.
-Chris

--
Chris Wilson, Intel Open Source Technology Centre

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 8658 bytes --]

[-- Attachment #2: Type: text/plain, Size: 599 bytes --]

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
z siedziba w Gdansku
ul. Slowackiego 173
80-298 Gdansk

Sad Rejonowy Gdansk Polnoc w Gdansku, 
VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, 
numer KRS 101882

NIP 957-07-52-316
Kapital zakladowy 200.000 zl

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: TIMESTAMP register

[Chris Wilson]

On Wed, 18 Apr 2012 07:53:36 +0000, "Lawrynowicz, Jacek" <jacek.lawrynowicz@intel.com> wrote:
> But how would I synchronize GPU and CPU clocks without access to the TIMESTAMP 
> register?
Issue a pipecontrol, compensate for the execution latency.

> And are you sure that over time both clocks won't desynchronize?
Given the assurrances made in the bspec, I'm certain the timestamp
will prove to be bogus and drift.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: TIMESTAMP register

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 2896 bytes --]

On Wed, 18 Apr 2012 00:51:42 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 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

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, this
   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.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx