Re: TIMESTAMP register

Lawrynowicz, Jacek
2012-04-17T20:34:14Z

[-- 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 --]