<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 3, 2016 at 8:34 PM, Robert Bragg <span dir="ltr"><<a href="mailto:robert@sixbynine.org" target="_blank">robert@sixbynine.org</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"><div dir="ltr"><div><div><div>Sorry for the delay replying to this, I missed it.<br></div></div></div><div><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres <span dir="ltr"><<a href="mailto:martin.peres@free.fr" target="_blank">martin.peres@free.fr</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"><span>On 20/04/16 17:23, Robert Bragg wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
Gen graphics hardware can be set up to periodically write snapshots of<br>
performance counters into a circular buffer via its Observation<br>
Architecture and this patch exposes that capability to userspace via the<br>
i915 perf interface.<br>
<br>
Cc: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>><br>
Signed-off-by: Robert Bragg <<a href="mailto:robert@sixbynine.org" target="_blank">robert@sixbynine.org</a>><br>
Signed-off-by: Zhenyu Wang <<a href="mailto:zhenyuw@linux.intel.com" target="_blank">zhenyuw@linux.intel.com</a>><br>
---<br>
drivers/gpu/drm/i915/i915_drv.h | 56 +-<br>
drivers/gpu/drm/i915/i915_gem_context.c | 24 +-<br>
drivers/gpu/drm/i915/i915_perf.c | 940 +++++++++++++++++++++++++++++++-<br>
drivers/gpu/drm/i915/i915_reg.h | 338 ++++++++++++<br>
include/uapi/drm/i915_drm.h | 70 ++-<br>
5 files changed, 1408 insertions(+), 20 deletions(-)<br>
<br></span>
+<span><br>
+<br>
+ /* It takes a fairly long time for a new MUX configuration to<br>
+ * be be applied after these register writes. This delay<br>
+ * duration was derived empirically based on the render_basic<br>
+ * config but hopefully it covers the maximum configuration<br>
+ * latency...<br>
+ */<br>
+ mdelay(100);<br>
</span></blockquote>
<br>
With such a HW and SW design, how can we ever expose hope to get any<br>
kind of performance when we are trying to monitor different metrics on each<br>
draw call? This may be acceptable for system monitoring, but it is problematic<br>
for the GL extensions :s<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Since it seems like we are going for a perf API, it means that for every change<br>
of metrics, we need to flush the commands, wait for the GPU to be done, then<br>
program the new set of metrics via an IOCTL, wait 100 ms, and then we may<br>
resume rendering ... until the next change. We are talking about a latency of<br>
6-7 frames at 60 Hz here... this is non-negligeable...<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I understand that we have a ton of counters and we may hide latency by not<br>
allowing using more than half of the counters for every draw call or frame, but<br>
even then, this 100ms delay is killing this approach altogether.<br></blockquote></div></div><div><br><div><br></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br>So revisiting this to double
check how things fail with my latest driver/tests without the delay, I apparently can't reproduce test failures without the delay any more...<br><br><div>I think the explanation is that since first adding the delay to the driver I also made the the driver a
bit more careful to not forward spurious reports that look invalid due
to a zeroed report id field, and that mechanism keeps the unit tests
happy, even though there are still some number of invalid reports generated if we don't wait.<br><br></div><div>One problem with simply having no delay is that the driver prints an error if it sees an invalid reports so I get a lot of 'Skipping
spurious, invalid OA report' dmesg spam. Also this was intended more as a last resort mechanism, and I wouldn't feel too happy about squashing the error message and potentially sweeping other error cases under the carpet.<br><br></div><div>Experimenting to see if the delay can at least be reduced, I brought the delay up in millisecond increments and found that although I still see a lot of spurious reports only waiting 1 or 5 milliseconds, at 10 milliseconds its reduced quite a bit and at 15 milliseconds I don't seem to have any errors.<br><br></div><div>15 milliseconds is still a long time, but at least not as long as 100.<br></div><br></div><div>Regards,<br></div><div>- Robert<br></div></div></div></div>