[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