From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Keith Packard" Subject: Re: [PATCH 6/7] vulkan: Add new VK_MESA_query_timestamp extension Date: Tue, 13 Feb 2018 13:11:25 -0800 Message-ID: <87inb0a936.fsf@keithp.com> References: <20180210044516.16944-1-keithp@keithp.com> <20180210044516.16944-7-keithp@keithp.com> <151848124266.9321.1645193817986214818@localhost.localdomain> <4a9ad7ce-b5af-b498-8816-6fcfb4009991@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0325213548==" Return-path: In-Reply-To: <4a9ad7ce-b5af-b498-8816-6fcfb4009991@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mesa-dev-bounces@lists.freedesktop.org Sender: "mesa-dev" To: Lionel Landwerlin , Dylan Baker , mesa-dev@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0325213548== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Lionel Landwerlin writes: > I'm assuming the correlation is done outside the vulkan driver? With a=20 > clock_gettime() maybe? > > If that's the case, I'm afraid this will be highly inaccurate. > The kernel might execute other tasks when the ioctl() happens and that=20 > might introduce (in my experience) a few milliseconds of delay. Yes, I agree. The trouble is that the window system layer works in one time base while the rendering layer works in the other, so there's no one driver which has access to both values, at least in Mesa. > I think if you want to do something like that, this has to be=20 > implemented in the kernel, making sure you disable interruptions while=20 > doing the correlation. That was my thinking originally, until I realized that there wasn't a single place which knew of the two clocks. Suggestions are welcome; I just don't know how the rendering driver is supposed to know what timebase the window system is running in? =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlqDVH0ACgkQ2yIaaQAA ABErFw/+JGwqSVzOKnU/uTQ6xyC7wHiIlmZWoBENsjwPQByzeNLx3IFgeeZG9UsH tqa9darUxyFUE52O2BqcnoP9IPhjIkkaBwQ8MaegFMq9TqLZ34/FsjvqRiWerHKd 5/QbiG1Fmcf6xt4hRWUluDYuACvLMuopd6qjOYLikO1Lb2Yjk8Zqwj2jR4GLYyFs VU+/WJJg2BVrqiO4v9hGEC8cLrR4qjJ9bN4mhiI2KJAIISr8urhGkXY8g+eC/+Ac S1lXihCBE02AMZjkZDZLWnZzb35rs6iQcKg6MpkjiQqVKep5SwuRyNRAtH/6721F nDWZQZzoCfnPqs2SlTsGMiZM2xgAFfoHnjJcHY3m9rF8NPJ1r2utPuhZB1fkIwsp Mfh4py1xsno59OQobt52pQwW6NfpE8wqptF8ETsZPrtTHWQXOGCe2HSIXbGOk8Ap kRG0ExcrHJMQ0g3mq+Akr/uO99stL/e0enk5WE05dW3FA/t2MM8TrwjtN8f4SW0V XTBDXmUMOnhO7SEyU3pPjRri+CmGJj6pr/wSBr0Lh/DQ9jwLUNn4QptC1l68ACRy ywMZKCuD0WxoCIDBAOM0m1qdJ/GSkssiohvFTeNLlwER/GtY6GTOaSkvEjzxDbR5 tB4uKed1V5O2vM4rT4QIp6MT6vDoK1Dn9TCeWaqJBQ7Cb0A+vco= =rm7g -----END PGP SIGNATURE----- --=-=-=-- --===============0325213548== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVzYS1kZXYg bWFpbGluZyBsaXN0Cm1lc2EtZGV2QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21lc2EtZGV2Cg== --===============0325213548==--