i965: Allow a per gen timebase scale factor

Prior to Skylake the Gen HW timestamps were driven by a 12.5MHz clock
with the convenient property of being able to scale by an integer (80)
to nanosecond units.

For Skylake the frequency is 12MHz or a scale factor of 83.333333

This updates gen_device_info to track a floating point timebase_scale
factor and makes corresponding _queryobj.c changes to no longer assume a
scale factor of 80 works across all gens.

Although the gen6_ code could have been been left alone, the changes
keep the code more comparable, and it now shares a few utility functions
for scaling raw timestamps and calculating deltas. The utility for
calculating deltas takes into account 32 or 36bit overflow depending on
the current kernel version.

Note: this leaves the timestamp handling of ARB_query_buffer_object
untouched, which continues to use an incorrect scale of 80 on Skylake
for now. This is more awkward to solve since the scaling is currently
done using a very limited uint64 ALU available to the command parser
that doesn't support multiply or divide where it's already taking a
large number of instructions just to effectively multiple by 80.

This fixes piglit arb_timer_query-timestamp-get on Skylake

v2: (Ken) Update timebase_scale for platforms past Skylake/Broxton too.

Signed-off-by: Robert Bragg <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>

2 files changed, 35 insertions, 2 deletions

diff --git a/src/intel/common/gen_device_info.c b/src/intel/common/gen_device_info.c
index 9bf3cd5cc42..209b293e510 100644
--- a/src/intel/common/gen_device_info.c
+++ b/src/intel/common/gen_device_info.c
@@ -36,6 +36,7 @@ static const struct gen_device_info gen_device_info_i965 = {
    .urb = {
       .size = 256,
    },
+   .timebase_scale = 80,
 };
 
 static const struct gen_device_info gen_device_info_g4x = {
@@ -51,6 +52,7 @@ static const struct gen_device_info gen_device_info_g4x = {
    .urb = {
       .size = 384,
    },
+   .timebase_scale = 80,
 };
 
 static const struct gen_device_info gen_device_info_ilk = {
@@ -65,6 +67,7 @@ static const struct gen_device_info gen_device_info_ilk = {
    .urb = {
       .size = 1024,
    },
+   .timebase_scale = 80,
 };
 
 static const struct gen_device_info gen_device_info_snb_gt1 = {
@@ -89,6 +92,7 @@ static const struct gen_device_info gen_device_info_snb_gt1 = {
          [MESA_SHADER_GEOMETRY] = 256,
       },
    },
+   .timebase_scale = 80,
 };
 
 static const struct gen_device_info gen_device_info_snb_gt2 = {
@@ -113,6 +117,7 @@ static const struct gen_device_info gen_device_info_snb_gt2 = {
          [MESA_SHADER_GEOMETRY] = 256,
       },
    },
+   .timebase_scale = 80,
 };
 
 #define GEN7_FEATURES                               \
@@ -121,7 +126,8 @@ static const struct gen_device_info gen_device_info_snb_gt2 = {
    .must_use_separate_stencil = true,               \
    .has_llc = true,                                 \
    .has_pln = true,                                 \
-   .has_surface_tile_offset = true
+   .has_surface_tile_offset = true,                 \
+   .timebase_scale = 80
 
 static const struct gen_device_info gen_device_info_ivb_gt1 = {
    GEN7_FEATURES, .is_ivybridge = true, .gt = 1,
@@ -287,7 +293,8 @@ static const struct gen_device_info gen_device_info_hsw_gt3 = {
    .max_tcs_threads = 504,                          \
    .max_tes_threads = 504,                          \
    .max_gs_threads = 504,                           \
-   .max_wm_threads = 384
+   .max_wm_threads = 384,                           \
+   .timebase_scale = 80
 
 static const struct gen_device_info gen_device_info_bdw_gt1 = {
    GEN8_FEATURES, .gt = 1,
@@ -385,6 +392,7 @@ static const struct gen_device_info gen_device_info_chv = {
    .max_tcs_threads = 336,                          \
    .max_tes_threads = 336,                          \
    .max_cs_threads = 56,                            \
+   .timebase_scale = 1000000000.0 / 12000000.0,     \
    .urb = {                                         \
       .size = 384,                                  \
       .min_entries = {                              \
@@ -410,6 +418,7 @@ static const struct gen_device_info gen_device_info_chv = {
    .max_tes_threads = 112,                         \
    .max_gs_threads = 112,                          \
    .max_cs_threads = 6 * 6,                        \
+   .timebase_scale = 1000000000.0 / 19200123.0,    \
    .urb = {                                        \
       .size = 192,                                 \
       .min_entries = {                             \
diff --git a/src/intel/common/gen_device_info.h b/src/intel/common/gen_device_info.h
index f0e8750d0ea..80676d0e003 100644
--- a/src/intel/common/gen_device_info.h
+++ b/src/intel/common/gen_device_info.h
@@ -147,6 +147,30 @@ struct gen_device_info
        */
       unsigned max_entries[4];
    } urb;
+
+   /**
+    * For the longest time the timestamp frequency for Gen's timestamp counter
+    * could be assumed to be 12.5MHz, where the least significant bit neatly
+    * corresponded to 80 nanoseconds.
+    *
+    * Since Gen9 the numbers aren't so round, with a a frequency of 12MHz for
+    * SKL (or scale factor of 83.33333333) and a frequency of 19200123Hz for
+    * BXT.
+    *
+    * For simplicty to fit with the current code scaling by a single constant
+    * to map from raw timestamps to nanoseconds we now do the conversion in
+    * floating point instead of integer arithmetic.
+    *
+    * In general it's probably worth noting that the documented constants we
+    * have for the per-platform timestamp frequencies aren't perfect and
+    * shouldn't be trusted for scaling and comparing timestamps with a large
+    * delta.
+    *
+    * E.g. with crude testing on my system using the 'correct' scale factor I'm
+    * seeing a drift of ~2 milliseconds per second.
+    */
+   double timebase_scale;
+
    /** @} */
 };