Re: [PATCH] dma-buf: Enhance dma-fence tracing

[Eric Anholt <eric@anholt.net>]

[-- Attachment #1.1: Type: text/plain, Size: 4110 bytes --]

Chris Wilson <chris@chris-wilson.co.uk> 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 client
>> > 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 avoid
>> > the pitfall of exposing low level details and so restrict ourselves only
>> > 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 tracepoint
>> > emission.
>> >
>> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> > Cc: Alex Deucher <alexdeucher@gmail.com>
>> > Cc: "Christian König" <christian.koenig@amd.com>
>> > Cc: Eric Anholt <eric@anholt.net>
>> > Cc: Pierre-Loup Griffais <pgriffais@valvesoftware.com>
>> > Cc: Michael Sartain <mikesart@fastmail.com>
>> > Cc: Steven Rostedt <rostedt@goodmis.org>
>> 
>> In general yes please! If possible please separate out the changes to 
>> 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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel