From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] dma-buf: Enhance dma-fence tracing Date: Thu, 24 Jan 2019 10:45:45 -0800 Message-ID: <875zudq4h2.fsf@anholt.net> References: <20190121232040.26114-1-chris@chris-wilson.co.uk> <3f469e3a-0b0f-fa06-9a5b-497bfa1cbee8@amd.com> <154814791621.1277.10783676492863339051@skylake-alporthouse-com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1655729602==" Return-path: In-Reply-To: <154814791621.1277.10783676492863339051@skylake-alporthouse-com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Chris Wilson , "Koenig, Christian" , "dri-devel@lists.freedesktop.org" Cc: Michael Sartain , Tvrtko Ursulin , "intel-gfx@lists.freedesktop.org" , Steven Rostedt , Pierre-Loup Griffais List-Id: dri-devel@lists.freedesktop.org --===============1655729602== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Chris Wilson writes: > Quoting Koenig, Christian (2019-01-22 08:49:30) >> Am 22.01.19 um 00:20 schrieb Chris Wilson: >> > Rather than every backend and GPU driver reinventing the same wheel for >> > user level debugging of HW execution, the common dma-fence framework >> > should include the tracing infrastructure required for most client API >> > level flow visualisation. >> > >> > With these common dma-fence level tracepoints, the userspace tools can >> > establish a detailed view of the client <-> HW flow across different >> > kernels. There is a strong ask to have this available, so that the >> > userspace developer can effectively assess if they're doing a good job >> > about feeding the beast of a GPU hardware. >> > >> > In the case of needing to look into more fine-grained details of how >> > kernel internals work towards the goal of feeding the beast, the tools >> > may optionally amend the dma-fence tracing information with the driver >> > implementation specific. But for such cases, the tools should have a >> > graceful degradation in case the expected extra tracepoints have >> > changed or their format differs from the expected, as the kernel >> > implementation internals are not expected to stay the same. >> > >> > It is important to distinguish between tracing for the purpose of clie= nt >> > flow visualisation and tracing for the purpose of low-level kernel >> > debugging. The latter is highly implementation specific, tied to >> > a particular HW and driver, whereas the former addresses a common goal >> > of user level tracing and likely a common set of userspace tools. >> > Having made the distinction that these tracepoints will be consumed for >> > client API tooling, we raise the spectre of tracepoint ABI stability. = It >> > is hoped that by defining a common set of dma-fence tracepoints, we av= oid >> > the pitfall of exposing low level details and so restrict ourselves on= ly >> > to the high level flow that is applicable to all drivers and hardware. >> > Thus the reserved guarantee that this set of tracepoints will be stable >> > (with the emphasis on depicting client <-> HW flow as opposed to >> > driver <-> HW). >> > >> > In terms of specific changes to the dma-fence tracing, we remove the >> > emission of the strings for every tracepoint (reserving them for >> > dma_fence_init for cases where they have unique dma_fence_ops, and >> > preferring to have descriptors for the whole fence context). strings do >> > not pack as well into the ftrace ringbuffer and we would prefer to >> > reduce the amount of indirect callbacks required for frequent tracepoi= nt >> > emission. >> > >> > Signed-off-by: Chris Wilson >> > Cc: Joonas Lahtinen >> > Cc: Tvrtko Ursulin >> > Cc: Alex Deucher >> > Cc: "Christian K=C3=B6nig" >> > Cc: Eric Anholt >> > Cc: Pierre-Loup Griffais >> > Cc: Michael Sartain >> > Cc: Steven Rostedt >>=20 >> In general yes please! If possible please separate out the changes to=20 >> the common dma_fence infrastructure from the i915 changes. > > Sure, I was just stressing the impact: remove some randomly placed > internal debugging tracepoints, try to define useful ones instead :) > > On the list of things to do was to convert at least 2 other drivers > (I was thinking nouveau/msm for simplicity, vc4 for a simpler > introduction to drm_sched than amdgpu) over to be sure we have the right > tracepoints. v3d is using gpu-scheduler, and I'd love to see it using some shared tracepoints -- I put in some of what we'd need for visualization, but I haven't actually built visualization yet so I'm not sure it's good enough. vc4 isn't using gpu-scheduler yet. I'm interested in it -- there's the user qpu pipeline that we should expose, but supporting another pipeline without the shared scheduler is no fun. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlxKB9oACgkQtdYpNtH8 nujQXhAAt1uXz31j5VdaBIQu2H+RBq7P2iWF/HTbS9mDEED43ND07ykeQl0yR82q vJL2ly6lwlWVGmD1Dn3aqULceMpd5rpadNj/NVVMKVgq2hEzOOX1hVyFrIY4Jr4F 9MKy5l2Dq2mRVEbOUzK6kamQL0U8f+CFAQ07sSU0K4LYg7uMqMjrrMHWjyvBvJal /l9Tfds7leIn45teImTmYuEbwe1/nt7YYeiydt66/MOif7NcVBhJ9I6k0Fy8zNww bTCsgqjNxSi5ZwErGh2uWLXzYpGgHvmqIiOVdyxnO6B/tXdXitnvqARlA8xZ0wf8 g94e+KQ8QsBOvL7MrRc0ZfnYrtvQgYqug04R74Vh6M0fRy+4ZkJj1Dgkab4fh6dv kvHbhsqr58mwt5kHUB/4IrjUnGBcVZl79i2mREQ3653SvdM/1AQ3ERCcAd1HOjMf 5SHQ/fyawtLCkzdaxd6YbgoTOWr+zVEajKhsx0MNIB5Wc0adIfgSEmhXWFxKNbzV noWJZb+aranfKByhBDc2ts30w1TCIYEFLqP4DpVPf1yZRB5duT40ZNbBXrYCm23W wzyLBWMLWvTATPXSqIJe4RsiuuR4hfzR2svoEM5ajW/XcDoVeZS32pJ6Qk0Kywor 8ZvWcnCtLOAuXdt1WxnaKB4ZXycTfEqwcY3zFaBcywmVDd1OJbU= =29Jq -----END PGP SIGNATURE----- --=-=-=-- --===============1655729602== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1655729602==--