On 04/12/2013 11:21 AM, Eric Anholt wrote:
Kenneth Graunke <kenn...@whitecape.org> writes:
Ironlake's counters are always enabled; userspace can simply send a
MI_REPROT_PERF_COUNT packet to take a snapshot of them. This makes it
easy to implement.
The counters are documented in the source code for the intel-gpu-tools
intel_perf_counters utility.
+/**
+ * i965 representation of a performance monitor object.
+ */
+struct brw_perf_monitor_object
+{
+ /** The base class. */
+ struct gl_perf_monitor_object base;
+
+ /**
+ * The GPU-facing BO, holding raw counter data in a hardware specific form.
+ */
+ drm_intel_bo *gpu_facing_bo;
+};
Why all the emphasis of "GPU-facing"? We don't use BOs for anything
that the GPU doesn't touch.
At one point, I thought that we returned the data to the application in
a buffer object...so we'd have two BOs, one GPU-facing, and one
API-facing. But we actually just copy it to them via a normal pointer,
so the careful distinction isn't necessary.
I'll rename it to "bo" in the next version.
+/**
+ * Driver hook for glEndPerformanceMonitorAMD().
+ */
+static void
+brw_end_perf_monitor(struct gl_context *ctx,
+ struct gl_perf_monitor_object *m)
+{
+ struct brw_context *brw = brw_context(ctx);
+ struct brw_perf_monitor_object *monitor = brw_perf_monitor(m);
+ if (aggregating_counters_needed(brw, m)) {
+ snapshot_aggregating_counters(brw, monitor->gpu_facing_bo,
+ brw->perfmon.total_counter_size);
At least some variants of the command require 64b alignment -- I'd
probably stick the ending dump at some fixed offset in the BO, like
halfway through.
Sounds like a good idea. It ended up working out, but using a fixed
2048 byte offset is guaranteed to work out and simplifies things.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
