[Intel-gfx] [PATCH] drm/i915/trace: add hw_id to gem requests trace points

[Lionel Landwerlin]

On 15/12/17 21:15, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2017-12-15 17:22:57)
>> On 15/12/2017 16:18, Lionel Landwerlin wrote:
>>> On 15/12/17 16:08, Chris Wilson wrote:
>>>> Quoting Lionel Landwerlin (2017-12-15 15:51:36)
>>>>> When monitoring the GPU with i915 perf, reports are tagged with a hw
>>>>> id. When also tracking the requests using the kernel tracepoints, if
>>>>> we include the hw_id from i915_gem_context, this allows us to
>>>>> correlate a process with hw id fields in the OA reports.
>>>> Maybe, but don't split the fence.context and fence.seqno. You should
>>>> also update the igt tools using the tracepoints.
>>>> -Chris
>>>>
>>> I would have thought the tools could deal with a different ordering :(
>> At least as a benefit you get to refresh your Perl skills. ;)
>>
>> trace.pl and intel-gpu-overlay I think are the only two.
>>
>> I guess it would be possible to smarten both up to detect where the
>> fields they need are located but maybe too much work.
> That's the thinking that got us into this mess to begin with ;)
>
> But yes, it may remain much easier to keep igt in line with the kernel
> and just say no to backwards-compatibility for these devtools.
> -Chris
>

Like I said on IRC, I wrote a small parser in peg : 
https://github.com/rib/gputop/blob/imgui/gputop-ui/tracepoint_format.leg
That's enough to get the fields' location/size, but not to interpret 
whether something's a pointer rather than u32/64.
Using a peg parser limits the pain quite a bit. Those should be 
available in python as well (don't know about perl).

-
Lionel