Mesa (master): i965: brw_context.h additions for OA unit query codegen

Robert Bragg rib at kemper.freedesktop.org
Thu Mar 9 13:50:34 UTC 2017


Module: Mesa
Branch: master
Commit: eaab41c9db1ddf320084b1af80c1da5e72160091
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=eaab41c9db1ddf320084b1af80c1da5e72160091

Author: Robert Bragg <robert at sixbynine.org>
Date:   Thu Jun  4 23:27:36 2015 +0100

i965: brw_context.h additions for OA unit query codegen

In preparation for generating code from the XML performance counter meta
data, this makes some additions to brw_context.h for this code to be
able to reference.

It adds a brw->perfquery.oa_metrics_table hash table for indexing built
up query descriptions by the GUID that is expected to be advertised by
the kernel (via sysfs) to be able to use that query.

It adds an 'OA_COUNTERS' brw_query_kind to be assigned to queries built
up by generated code.

It adds a brw->perfquery.sys_vars structure to have a consistent place
to represent the different system variables like $EuCoresTotalCount and
$EuSlicesTotalCount that are referenced by OA counter normalization
equations.

  Although extending + referencing gen_device_info for these variables
  was considered, these are some of the (mostly minor) reasons for
  going with a dedicated structure:

  - Currently we only need this info for the performance_query backend
    and it might be a bit tedious to go back and initialize the state
    for pre-Haswell devinfo structures.
  - Considering the $SubsliceMask then the requirement for how multiple
    per-slice masks are packed only comes from how the variables are
    references by availability tests in XML, and might not be a good
    general representation for tracking subslice masks if another use
    case arises.
  - If we used gen_device_info then we'd likely want to avoid making
    assumptions about the C types during codegen and adding explicit
    casts, while that's not necessary with a dedicated struct with all
    members being uint64_t.
  - This structure and the code for initializing it is currently shared
    (just through copy & paste) with a few other projects dealing with
    OA counters, and that's been convenient so far.

Signed-off-by: Robert Bragg <robert at sixbynine.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
Acked-by: Kenneth Graunke <kenneth at whitecape.org>

---

 src/mesa/drivers/dri/i965/brw_context.h | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h
index 96e225c..8f6bf18 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -594,6 +594,7 @@ struct shader_times;
 struct gen_l3_config;
 
 enum brw_query_kind {
+   OA_COUNTERS,
    PIPELINE_STATS
 };
 
@@ -1078,6 +1079,26 @@ struct brw_context
    } predicate;
 
    struct {
+      /* Variables referenced in the XML meta data for OA performance
+       * counters, e.g in the normalization equations.
+       *
+       * All uint64_t for consistent operand types in generated code
+       */
+      struct {
+         uint64_t timestamp_frequency; /** $GpuTimestampFrequency */
+         uint64_t n_eus;               /** $EuCoresTotalCount */
+         uint64_t n_eu_slices;         /** $EuSlicesTotalCount */
+         uint64_t subslice_mask;       /** $SubsliceMask */
+         uint64_t gt_min_freq;         /** $GpuMinFrequency */
+         uint64_t gt_max_freq;         /** $GpuMaxFrequency */
+      } sys_vars;
+
+      /* OA metric sets, indexed by GUID, as know by Mesa at build time,
+       * to cross-reference with the GUIDs of configs advertised by the
+       * kernel at runtime
+       */
+      struct hash_table *oa_metrics_table;
+
       struct brw_perf_query_info *queries;
       int n_queries;
 




More information about the mesa-commit mailing list