From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Keith Packard" Subject: Re: [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v4] Date: Tue, 16 Oct 2018 14:07:32 -0700 Message-ID: <8736t58usr.fsf@keithp.com> References: <20181015230515.3695-1-keithp@keithp.com> <20181016053150.11453-1-keithp@keithp.com> <87bm7t8z3k.fsf@keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1607451116==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jason Ekstrand Cc: ML mesa-dev , Maling list - DRI developers List-Id: dri-devel@lists.freedesktop.org --===============1607451116== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jason Ekstrand writes: > I think what Bas is getting at is that there are two problems: > > 1) We are not sampling at exactly the same time > 2) The two clocks may not tick at exactly the same time. Thanks for the clarification. > If we want to be conservative, I suspect Bas may be right that adding is > the safer thing to do. Yes, it's certainly safe to increase the value of maxDeviation. Currently, the time it takes to sample all of the clocks is far larger than the GPU tick, so adding that in would not have a huge impact on the value returned to the application. I'd like to dig in a little further and actually understand if the current computation (which is derived directly from the Vulkan spec) is wrong, and if so, whether the spec needs to be adjusted. I think the question is what 'maxDeviation' is supposed to represent. All the spec says is: * pMaxDeviation is a pointer to a 64-bit unsigned integer value in which the strictly positive maximum deviation, in nanoseconds, of the calibrated timestamp values is returned. I interpret this as the maximum error in sampling the individual clocks, which is to say that the clock values are guaranteed to have been sampled within this interval of each other. So, if we have a monotonic clock and GPU clock: 0 1 2 3 4 5 6 7 8 9 a b c d e f Monotonic -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- 0 1 2 3 GPU -----_____-----_____-----_____-----_____ gpu_period in this case is 5 ticks of the monotonic clock. Now, I perform three operations: start =3D read(monotonic) gpu =3D read(GPU) end =3D read(monotonic) Let's say that: start =3D 2 GPU =3D 1 * 5 =3D 5 monotonic equivalent ticks end =3D b So, the question is only how large the error between GPU and start could possibly be. Certainly the GPU clock was sampled some time between when monotonic tick 2 started and monotonic tick b ended. But, we have no idea what phase the GPU clock was in when sampled. Let's imagine we manage to sample the GPU clock immediately after the first monotonic sample. I'll shift the offset of the monotonic and GPU clocks to retain the same values (start =3D 2, GPU =3D 1), but now the GPU clock is being sampled immediately after monotonic time 2: w x y z 0 1 2 3 4 5 6 7 8 9 a b c d e f Monotonic -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- 0 1 2 3 GPU -----_____-----_____-----_____-----_____ In this case, the GPU tick started at monotonic time y, nearly 5 monotonic ticks earlier than the measured monotonic time, so the deviation between GPU and monotonic would be 5 ticks. If we sample the GPU clock immediately before the second monotonic sample, then that GPU tick either starts earlier than the range, in which case the above evaluation holds, or the GPU tick is entirely contained within the range: 0 1 2 3 4 5 6 7 8 9 a b c d e f Monotonic -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- z 0 1 2 3 GPU __-----_____-----_____-----_____-----_____----- In this case, the deviation between the first monotonic sample (that returned to the application as the monotonic time) and the GPU sample is the whole interval of measurement (b - 2). I think I've just managed to convince myself that Jason's first suggestion (max2(sample interval, gpu interval)) is correct, although I think we should add '1' to the interval to account for sampling phase errors in the monotonic clock. As that's measured in ns, and I'm currently getting values in the =C2=B5s range, that's a small error in comparison. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlvGUxQACgkQ2yIaaQAA ABHqsA/+N5ICOmR0y124Ieq9LzUWVUEJ+U7Tux0hY60n2k7TcphM/rPBUC66RmaX 6fDUwWDecpXGt6afEQEduAad0XHTLbeIONaclSvDPD8km6h1wAKi/Ep1GLj5ABLv w45vK2V/ece6OI4JGBNSFfZYYtciajbApr15oWT3HQ1rciE9k7NvE7etpV2S6iQb nDf43RtWZdnsAl5hGtkcA4EvHVdez957ZrJ4lDCxRw1+JIiVZdB28XjH6ef3q3OG 1eSzio0jNgzz1rY2YkQD0D0WfASxs8/zD9HXq92NuDgONNzPg0xxgd8jMfezpgoB /hP/hjWYZCoF2v2FJLopI3agD/BlOTmhisfM8DCxI5F9CoideZknGCZrI05GWJud CcSTqAPh/U6qV/g+iOM4N2Tf1q+FkGM9/T9Wj/ailM9yFR5D3WpUaJLjhUwYr7fG efrGkhb6dvwrlhZ+FwE+Yk6xmmVqu0X0FuVA2wt8yB3WiqjD5LVNQEEZ0QoZvdDK NsLZeavREoYQRluV9bYpfnaFW4nVRQxpy1k4QmqzI8pN2vQvX/BuSXhlIaJfUCp7 YwEVvqwVlRMLI8RBqnrpjurwfZElB6QyH7OYGeCRtKR8EEy6buV7F9gjo9zh/45s nWa4yotJ57avQzlbAr+UT4UdEEZblEhSjMYMPKwDMO2RCX0gy5k= =B4v1 -----END PGP SIGNATURE----- --=-=-=-- --===============1607451116== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1607451116==--