<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 12/5/2017 8:07 PM, Lionel Landwerlin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:426e5216-4346-ba17-f220-56ac8ad3409e@intel.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix">On 05/12/17 14:28, Robert Bragg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMou1-0j1XG2dpDyUOmdfeW_WN3Om89ALh=X-z2vyY7midd-OA@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Dec 5, 2017 at 2:16 PM,
Lionel Landwerlin <span dir="ltr"><<a
href="mailto:lionel.g.landwerlin@intel.com"
target="_blank" moz-do-not-send="true">lionel.g.landwerlin@intel.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hey Sagar,<br>
<br>
Sorry for the delay looking into this series.<br>
I've done some userspace/UI work in GPUTop to try to
correlate perf samples/tracepoints with i915 perf
reports.<br>
<br>
I wanted to avoid having to add too much logic into the
kernel and tried to sample both cpu clocks & gpu
timestamps from userspace.<br>
So far that's not working. People more knowledgable than
I would have realized that the kernel can sneak in work
into syscalls.<br>
So result is that 2 syscalls (one to get the cpu clock,
one for the gpu timestamp) back to back from the same
thread leads to time differences of anywhere from a few
microseconds to in some cases close to 1millisecond. So
it's basically unworkable.<br>
Anyway the UI work won't go to waste :)<br>
<br>
I'm thinking to go with your approach.<br>
>From my experiment with gputop, it seems we might
want to use a different cpu clock source though or make
it configurable.<br>
The perf infrastructure allows you to choose what clock
you want to use. Since we want to avoid time adjustments
on that clock (because we're adding deltas), a clock
monotonic raw would make most sense.<br>
</blockquote>
<div><br>
</div>
<div>I would guess the most generally useful clock domain
to correlate with the largest number of interesting
events would surely be CLOCK_MONOTONIC, not
_MONOTONIC_RAW.</div>
<div><br>
</div>
<div>E.g. here's some discussion around why vblank events
use CLOCK_MONOTINIC: <a
href="https://lists.freedesktop.org/archives/dri-devel/2012-October/028878.html"
moz-do-not-send="true">https://lists.freedesktop.org/archives/dri-devel/2012-October/028878.html</a><br>
</div>
<div><br>
</div>
<div>Br,</div>
<div>- Robert<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Thanks Rob, then I guess making it configurable when opening the
stream would be the safest option.<br>
<br>
</blockquote>
<pre>All timecounter users today rely on monotonic clock (Can request for clock real/wall time, clock boot time, clock tai time
corresponding to monotonic clock).
Agree that we will need to have configuration option about clock to be used like in trace_clock in ftrace.
</pre>
<blockquote type="cite"
cite="mid:426e5216-4346-ba17-f220-56ac8ad3409e@intel.com">
<blockquote type="cite"
cite="mid:CAMou1-0j1XG2dpDyUOmdfeW_WN3Om89ALh=X-z2vyY7midd-OA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> <br>
I'll look at adding some tests for this too.<br>
<br>
Thanks,<br>
<br>
-<br>
Lionel<span class="gmail-im gmail-HOEnZb"><br>
<br>
On 15/11/17 12:13, Sagar Arun Kamble wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> We can compute
system time corresponding to GPU timestamp by taking
a<br>
reference point (CPU monotonic time, GPU timestamp)
and then adding<br>
delta time computed using timecounter/cyclecounter
support in kernel.<br>
We have to configure cyclecounter with the GPU
timestamp frequency.<br>
Earlier approach that was based on cross-timestamp
is not needed. It<br>
was being used to approximate the frequency based on
invalid assumptions<br>
(possibly drift was being seen in the time due to
precision issue).<br>
The precision of time from GPU clocks is already in
ns and timecounter<br>
takes care of it as verified over variable
durations.<br>
<br>
This series adds base timecounter/cyclecounter
changes and changes to<br>
get GPU and CPU timestamps in OA samples.<br>
<br>
Sagar Arun Kamble (1):<br>
drm/i915/perf: Add support to correlate GPU
timestamp with system time<br>
<br>
Sourab Gupta (3):<br>
drm/i915/perf: Add support for collecting 64 bit
timestamps with OA<br>
reports<br>
drm/i915/perf: Extract raw GPU timestamps from OA
reports<br>
drm/i915/perf: Send system clock monotonic time
in perf samples<br>
<br>
drivers/gpu/drm/i915/i915_drv.<wbr>h | 11 ++++<br>
drivers/gpu/drm/i915/i915_perf<wbr>.c | 124
++++++++++++++++++++++++++++++<wbr>++++++++-<br>
drivers/gpu/drm/i915/i915_reg.<wbr>h | 6 ++<br>
include/uapi/drm/i915_drm.h | 14 +++++<br>
4 files changed, 154 insertions(+), 1 deletion(-)<br>
<br>
</blockquote>
<br>
</span>
<div class="gmail-HOEnZb">
<div class="gmail-h5"> ______________________________<wbr>_________________<br>
Intel-gfx mailing list<br>
<a href="mailto:Intel-gfx@lists.freedesktop.org"
target="_blank" moz-do-not-send="true">Intel-gfx@lists.freedesktop.or<wbr>g</a><br>
<a
href="https://lists.freedesktop.org/mailman/listinfo/intel-gfx"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.freedesktop.org/<wbr>mailman/listinfo/intel-gfx</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<p><br>
</p>
</blockquote>
<br>
</body>
</html>