diff options
author | Robert Bragg <[email protected]> | 2016-10-27 22:08:19 +0100 |
---|---|---|
committer | Robert Bragg <[email protected]> | 2017-03-17 15:45:19 +0000 |
commit | 344d1a4015de94d27c20ea6f632be8e4c16b6a63 (patch) | |
tree | bd7b661388bc3f659bf1608e9f4d190751b1c0a7 /src/mesa/drivers | |
parent | 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d (diff) |
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]>
Diffstat (limited to 'src/mesa/drivers')
-rw-r--r-- | src/mesa/drivers/dri/i965/brw_context.c | 15 | ||||
-rw-r--r-- | src/mesa/drivers/dri/i965/brw_context.h | 3 | ||||
-rw-r--r-- | src/mesa/drivers/dri/i965/brw_queryobj.c | 58 | ||||
-rw-r--r-- | src/mesa/drivers/dri/i965/gen6_queryobj.c | 28 |
4 files changed, 79 insertions, 25 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c index 32cfb2efe4c..648ae508145 100644 --- a/src/mesa/drivers/dri/i965/brw_context.c +++ b/src/mesa/drivers/dri/i965/brw_context.c @@ -524,6 +524,21 @@ brw_initialize_context_constants(struct brw_context *brw) ctx->Const.MaxCombinedShaderOutputResources = MAX_IMAGE_UNITS + BRW_MAX_DRAW_BUFFERS; + /* The timestamp register we can read for glGetTimestamp() is + * sometimes only 32 bits, before scaling to nanoseconds (depending + * on kernel). + * + * Once scaled to nanoseconds the timestamp would roll over at a + * non-power-of-two, so an application couldn't use + * GL_QUERY_COUNTER_BITS to handle rollover correctly. Instead, we + * report 36 bits and truncate at that (rolling over 5 times as + * often as the HW counter), and when the 32-bit counter rolls + * over, it happens to also be at a rollover in the reported value + * from near (1<<36) to 0. + * + * The low 32 bits rolls over in ~343 seconds. Our 36-bit result + * rolls over every ~69 seconds. + */ ctx->Const.QueryCounterBits.Timestamp = 36; ctx->Const.MaxTextureCoordUnits = 8; /* Mesa limit */ diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h index 024f4b5e98b..6f4dbe81c37 100644 --- a/src/mesa/drivers/dri/i965/brw_context.h +++ b/src/mesa/drivers/dri/i965/brw_context.h @@ -1298,6 +1298,9 @@ void brw_emit_query_begin(struct brw_context *brw); void brw_emit_query_end(struct brw_context *brw); void brw_query_counter(struct gl_context *ctx, struct gl_query_object *q); bool brw_is_query_pipelined(struct brw_query_object *query); +uint64_t brw_timebase_scale(struct brw_context *brw, uint64_t gpu_timestamp); +uint64_t brw_raw_timestamp_delta(struct brw_context *brw, + uint64_t time0, uint64_t time1); /** gen6_queryobj.c */ void gen6_init_queryobj_functions(struct dd_function_table *functions); diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c b/src/mesa/drivers/dri/i965/brw_queryobj.c index 40b86a0f64b..5c3ecbafba6 100644 --- a/src/mesa/drivers/dri/i965/brw_queryobj.c +++ b/src/mesa/drivers/dri/i965/brw_queryobj.c @@ -42,6 +42,42 @@ #include "brw_state.h" #include "intel_batchbuffer.h" +uint64_t +brw_timebase_scale(struct brw_context *brw, uint64_t gpu_timestamp) +{ + const struct gen_device_info *devinfo = &brw->screen->devinfo; + + return (double)gpu_timestamp * devinfo->timebase_scale; +} + +/* As best we know currently, the Gen HW timestamps are 36bits across + * all platforms, which we need to account for when calculating a + * delta to measure elapsed time. + * + * The timestamps read via glGetTimestamp() / brw_get_timestamp() sometimes + * only have 32bits due to a kernel bug and so in that case we make sure to + * treat all raw timestamps as 32bits so they overflow consistently and remain + * comparable. (Note: the timestamps being passed here are not from the kernel + * so we don't need to be taking the upper 32bits in this buggy kernel case we + * are just clipping to 32bits here for consistency.) + */ +uint64_t +brw_raw_timestamp_delta(struct brw_context *brw, uint64_t time0, uint64_t time1) +{ + if (brw->screen->hw_has_timestamp == 2) { + /* Kernel clips timestamps to 32bits in this case, so we also clip + * PIPE_CONTROL timestamps for consistency. + */ + return (uint32_t)time1 - (uint32_t)time0; + } else { + if (time0 > time1) { + return (1ULL << 36) + time1 - time0; + } else { + return time1 - time0; + } + } +} + /** * Emit PIPE_CONTROLs to write the current GPU timestamp into a buffer. */ @@ -117,12 +153,18 @@ brw_queryobj_get_results(struct gl_context *ctx, /* The query BO contains the starting and ending timestamps. * Subtract the two and convert to nanoseconds. */ - query->Base.Result += 1000 * ((results[1] >> 32) - (results[0] >> 32)); + query->Base.Result = brw_raw_timestamp_delta(brw, results[0], results[1]); + query->Base.Result = brw_timebase_scale(brw, query->Base.Result); break; case GL_TIMESTAMP: /* The query BO contains a single timestamp value in results[0]. */ - query->Base.Result = 1000 * (results[0] >> 32); + query->Base.Result = brw_timebase_scale(brw, results[0]); + + /* Ensure the scaled timestamp overflows according to + * GL_QUERY_COUNTER_BITS + */ + query->Base.Result &= (1ull << ctx->Const.QueryCounterBits.Timestamp) - 1; break; case GL_SAMPLES_PASSED_ARB: @@ -508,9 +550,15 @@ brw_get_timestamp(struct gl_context *ctx) break; } - /* See logic in brw_queryobj_get_results() */ - result *= 80; - result &= (1ull << 36) - 1; + /* Scale to nanosecond units */ + result = brw_timebase_scale(brw, result); + + /* Ensure the scaled timestamp overflows according to + * GL_QUERY_COUNTER_BITS. Technically this isn't required if + * querying GL_TIMESTAMP via glGetInteger but it seems best to keep + * QueryObject and GetInteger timestamps consistent. + */ + result &= (1ull << ctx->Const.QueryCounterBits.Timestamp) - 1; return result; } diff --git a/src/mesa/drivers/dri/i965/gen6_queryobj.c b/src/mesa/drivers/dri/i965/gen6_queryobj.c index 98cbbff9140..0014a67e719 100644 --- a/src/mesa/drivers/dri/i965/gen6_queryobj.c +++ b/src/mesa/drivers/dri/i965/gen6_queryobj.c @@ -219,30 +219,18 @@ gen6_queryobj_get_results(struct gl_context *ctx, /* The query BO contains the starting and ending timestamps. * Subtract the two and convert to nanoseconds. */ - query->Base.Result += 80 * (results[1] - results[0]); + query->Base.Result = brw_raw_timestamp_delta(brw, results[0], results[1]); + query->Base.Result = brw_timebase_scale(brw, query->Base.Result); break; case GL_TIMESTAMP: - /* Our timer is a clock that increments every 80ns (regardless of - * other clock scaling in the system). The timestamp register we can - * read for glGetTimestamp() masks out the top 32 bits, so we do that - * here too to let the two counters be compared against each other. - * - * If we just multiplied that 32 bits of data by 80, it would roll - * over at a non-power-of-two, so an application couldn't use - * GL_QUERY_COUNTER_BITS to handle rollover correctly. Instead, we - * report 36 bits and truncate at that (rolling over 5 times as often - * as the HW counter), and when the 32-bit counter rolls over, it - * happens to also be at a rollover in the reported value from near - * (1<<36) to 0. - * - * The low 32 bits rolls over in ~343 seconds. Our 36-bit result - * rolls over every ~69 seconds. - * - * The query BO contains a single timestamp value in results[0]. + /* The query BO contains a single timestamp value in results[0]. */ + query->Base.Result = brw_timebase_scale(brw, results[0]); + + /* Ensure the scaled timestamp overflows according to + * GL_QUERY_COUNTER_BITS */ - query->Base.Result = 80 * (results[0] & 0xffffffff); - query->Base.Result &= (1ull << 36) - 1; + query->Base.Result &= (1ull << ctx->Const.QueryCounterBits.Timestamp) - 1; break; case GL_SAMPLES_PASSED_ARB: |