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 12:34:39 -0700 Message-ID: <87bm7t8z3k.fsf@keithp.com> References: <20181015230515.3695-1-keithp@keithp.com> <20181016053150.11453-1-keithp@keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0678932277==" 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: Bas Nieuwenhuizen Cc: mesa-dev , ML dri-devel List-Id: dri-devel@lists.freedesktop.org --===============0678932277== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Bas Nieuwenhuizen writes: >> + end =3D radv_clock_gettime(CLOCK_MONOTONIC_RAW); >> + >> + uint64_t clock_period =3D end - begin; >> + uint64_t device_period =3D DIV_ROUND_UP(1000000, clock_crystal_f= req); >> + >> + *pMaxDeviation =3D MAX2(clock_period, device_period); > > Should this not be a sum? Those deviations can happen independently > from each other, so worst case both deviations happen in the same > direction which causes the magnitude to be combined. This use of MAX2 comes right from one of the issues raised during work on the extension: 8) Can the maximum deviation reported ever be zero? RESOLVED: Unless the tick of each clock corresponding to the set of time domains coincides and all clocks can literally be sampled simutaneously, there isn=E2=80=99t really a possibility for the maximum deviation to be zero, so by convention the maximum deviation is always at least the maximum of the length of the ticks of the set of time domains calibrated and thus can never be zero. I can't wrap my brain around this entirely, but I think that this says that the deviation reported is supposed to only reflect the fact that we aren't sampling the clocks at the same time, and so there may be a 'tick' of error for any sampled clock. If you look at the previous issue in the spec, that actually has the pseudo code I used in this implementation for computing maxDeviation which doesn't include anything about the time period of the GPU. Jason suggested using the GPU period as the minimum value for maxDeviation at the GPU time period to make sure we never accidentally returned zero, as that is forbidden by the spec. We might be able to use 1 instead, but it won't matter in practice as the time it takes to actually sample all of the clocks is far longer than a GPU tick. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlvGPVAACgkQ2yIaaQAA ABEXLQ//ehaI5YOD0vlm59gMFMSN8uiqj1J8fHe/4VA++ilHSpda7iqmezHTtRjK P/6pG72SSP/GsFEUN+BnU1AQy5rBON/pPB+Rivv78MDG7073XxknjlzyheJGQn5s W8zrllIGdIwyad9L4xCFSazWi5FLW1Zm1n7kNDuPs9ApxNdMV6HSbWG+Ge8qJNPD xWOV756cl+ZEbz2Qb/malAxBP2acuVYE3hmDkya2VuRzPXSfPAnx6gRDzlNnR/V4 TVYfSaSUpmKAP3sFzXH7MqPPlSpfpm/iJaw35u2ESasYMVrgA17SUb9XYEp7nFsu Xz+RGCpvzBiS8A6tbtZBy92ZSYc5GOx/sQ4t0lMNPaf2GqVfQPvS1W6CHYtcM3KI FZum7/H556DHVNGPvHAIijATftIixgpZcCi/yH4ikVM5+btTyMUwLucwAocGYQq4 DK7I+xv5LJY3JsGHTv0+GjJgFSs1B0MZHor4ZBr2CdoGHq+wXg4mCxfg0q9rCvnr P7FY1qhazqaa0PB/XfuuR8PoOtpTihX8VRUk3pBY2E6WgApPro5AhGOeAV7kPIwL dZeBLc6ecZ5gD5GbQf50OmC9wBl/1JH5/y4drBSzEHJA1vWdhemuaES0JN15TnZj Oz/I9vT5VCHWxtEyM/amZoZBHBEESH/N06uUS0Vp79jcK92Qrok= =sFn/ -----END PGP SIGNATURE----- --=-=-=-- --===============0678932277== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0678932277==--