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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
