[Intel-gfx] uABI / Removing DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig
Michael Sartain
mikesart at fastmail.com
Thu Dec 20 18:27:19 UTC 2018
On Wed, Dec 19, 2018, at 12:22 PM, Steven Rostedt wrote:
> On Wed, 19 Dec 2018 12:08:18 +0200
> Joonas Lahtinen <joonas.lahtinen at linux.intel.com> wrote:
>·
> > To me, it seems almost as if folks are too preoccupied with thinking if
> > we somehow can do this through tracepoints, to stop and actually think
> > if we should.
>·
> Regardless of whether it should or shouldn't, one solution to this is
> to make the trace event in question record basically nothing but a
> pointer.
Right now, these are the events I'm capturing w/ an AMD gpu:
amdgpu_cs:0-1150 [002] 630662.649417: amdgpu_cs_ioctl: sched_job=3490671, timeline=gfx, context=105, seqno=3081096, ring_name=ffff91cb1ab1bdd0, num_ibs=3
gfx-190 [000] 630662.649451: amdgpu_sched_run_job: sched_job=3490671, timeline=gfx, context=105, seqno=3081096, ring_name=ffff91cb1ab1bdd0, num_ibs=3
gfx-190 [000] 630662.649454: dma_fence_signaled: driver=amd_sched timeline=gfx context=104 seqno=3081096
With Intel gpu (and rebuilt kernel w/ CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS):
<idle>-0 [002] 821.717208: intel_engine_notify: dev=0, engine=0:0, seqno=38896, waiters=1
RenderThread-1024 [002] 825.722358: i915_request_queue: dev=0, engine=0:0, hw_id=9, ctx=30, seqno=38896, flags=0x0
RenderThread-1024 [002] 825.722371: i915_request_add: dev=0, engine=0:0, hw_id=9, ctx=30, seqno=38896, global=0
RenderThread-1024 [002] 825.722372: i915_request_submit: dev=0, engine=0:0, hw_id=9, ctx=30, seqno=38896, global=0
RenderThread-1024 [002] 825.745964: i915_request_execute: dev=0, engine=0:0, hw_id=9, ctx=30, seqno=38896, global=42199
RenderThread-1024 [002] 825.745964: i915_request_in: dev=0, engine=0:0, hw_id=9, ctx=30, seqno=38896, prio=0, global=42199, port=1
<idle>-0 [002] 825.755943: intel_engine_notify: dev=0, engine=0:0, seqno=42199, waiters=1
It's quite obvious that just because gpuvis sees those amdgpu tracepoints when
running with the AMD card and parses and displays those, it does *not* get
those same tracepoints when I run with an Intel gpu.
And with my Iris Pro Graphics 580 Gen9, I can reasonably expect to get the
above i915 tracepoints.
But if I install a new Intel Xe Gen11, why should I expect to see those Gen9
i915 tracepoint events? Is it because we are tying tracepoints and the
created uABI to *kernel modules* and not the hardware?
I'm asking, because personally I would expect the hardware to drive these
tracepoint events, much like I check cpu flags to see whether I can run AVX
code, or perf has intel_pt recording on one machine, but not another.
Right now gpuvis graphs the above events in an easy to understand view.
Occasionally, it's really nice to use trace-cmd to get textual representation
for grepping, etc. Storing pointers would obviously break that. I guess if it's
what we need to do to avoid the uABI problem, then it's what we do - still
better than using an entirely new tracing system if we can avoid that.
Thanks much.
-Mike
More information about the Intel-gfx
mailing list