Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> >> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> >> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> >> > Cc: Alex Deucher <alexdeucher@xxxxxxxxx> >> > Cc: "Christian König" <christian.koenig@xxxxxxx> >> > Cc: Eric Anholt <eric@xxxxxxxxxx> >> > Cc: Pierre-Loup Griffais <pgriffais@xxxxxxxxxxxxxxxxx> >> > Cc: Michael Sartain <mikesart@xxxxxxxxxxxx> >> > Cc: Steven Rostedt <rostedt@xxxxxxxxxxx> >> >> 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:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
