Sorry for the delay replying to this, I missed it.On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres <martin.peres@free.fr> wrote:On 20/04/16 17:23, Robert Bragg wrote:
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
---
drivers/gpu/drm/i915/i915_drv.h | 56 +-
drivers/gpu/drm/i915/i915_gem_context.c | 24 +-
drivers/gpu/drm/i915/i915_perf.c | 940 +++++++++++++++++++++++++++++++-
drivers/gpu/drm/i915/i915_reg.h | 338 ++++++++++++
include/uapi/drm/i915_drm.h | 70 ++-
5 files changed, 1408 insertions(+), 20 deletions(-)
+
+
+ /* It takes a fairly long time for a new MUX configuration to
+ * be be applied after these register writes. This delay
+ * duration was derived empirically based on the render_basic
+ * config but hopefully it covers the maximum configuration
+ * latency...
+ */
+ mdelay(100);
With such a HW and SW design, how can we ever expose hope to get any
kind of performance when we are trying to monitor different metrics on each
draw call? This may be acceptable for system monitoring, but it is problematic
for the GL extensions :s
Since it seems like we are going for a perf API, it means that for every change
of metrics, we need to flush the commands, wait for the GPU to be done, then
program the new set of metrics via an IOCTL, wait 100 ms, and then we may
resume rendering ... until the next change. We are talking about a latency of
6-7 frames at 60 Hz here... this is non-negligeable...
I understand that we have a ton of counters and we may hide latency by not
allowing using more than half of the counters for every draw call or frame, but
even then, this 100ms delay is killing this approach altogether.