[lkml]   [2014]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/3] Expose gpu counters via perf pmu driver

* Robert Bragg <> wrote:

> > I'd strong[ly] suggest thinking about sampling as well, if
> > the hardware exposes sample information: at least for
> > profiling CPU loads the difference is like day and night,
> > compared to aggregated counts and self-profiling.
> Here I was thinking of counters or data that can be sampled via
> mmio using a hrtimer. E.g. the current gpu frequency or the
> energy usage. I'm not currently aware of any capability for the
> gpu to say trigger an interrupt after a threshold number of
> events occurs (like clock cycles) so I think we may generally
> be limited to a wall clock time domain for sampling.

In general hrtimer-driven polling gives pretty good profiling
information as well - key is to be able to get a sample of EU
thread execution state.

(Trigger thresholds and so can be useful as well, but are a
second order concern in terms of profiling quality.)

> > It's a very good idea to not expose such limitations to
> > user-space - the GPU driver doing the necessary hrtimer
> > polling to construct a proper count is a much higher quality
> > solution.
> That sounds preferable.
> I'm open to suggestions for finding another way for userspace
> to initiate a flush besides through read() in case there's a
> concern that might be set a bad precedent. For the i915_oa
> driver it seems ok at the moment since we don't currently
> report a useful counter through read() and for the main use
> case where we want the flushing we expect that most of the time
> there won't be any significant cost involved in flushing since
> we'll be using a very low timer period. Maybe this will bite us
> later though.

You could add an ioctl() as well - we are not religious about
them, there's always things that are special enough to not
warrant a generic syscall.

Anyway, aggregate counts alone are obviously very useful to
analyzing GPU performance, so your initial approach looks
perfectly acceptable to me already.



 \ /
  Last update: 2014-11-16 11:01    [W:0.137 / U:2.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site