[Mesa-dev] [PATCH v3 3/5] i965: perf: read slice/unslice frequencies from OA reports

[Kenneth Graunke]

On Tuesday, April 17, 2018 5:24:56 PM PDT Lionel Landwerlin wrote:
> v2: Add comment breaking down where the frequency values come from (Ken)
> 
> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
> ---
>  .../drivers/dri/i965/brw_performance_query.c  | 49 +++++++++++++++++++
>  .../drivers/dri/i965/brw_performance_query.h  | 12 +++++
>  2 files changed, 61 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c b/src/mesa/drivers/dri/i965/brw_performance_query.c
> index 32cf96a333d..03ba4942070 100644
> --- a/src/mesa/drivers/dri/i965/brw_performance_query.c
> +++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
> @@ -1341,6 +1341,54 @@ brw_is_perf_query_ready(struct gl_context *ctx,
>     return false;
>  }
>  
> +static void
> +gen8_read_report_clock_ratios(const uint32_t *report,
> +                              uint64_t *slice_freq_hz,
> +                              uint64_t *unslice_freq_hz)
> +{
> +   /* The lower 16bits of the RPT_ID field of the OA reports contains a
> +    * snapshot of the bits coming from the RP_FREQ_NORMAL register and is
> +    * divided this way :
> +    *
> +    * RPT_ID[31:25]: RP_FREQ_NORMAL[20:14] (low squashed_slice_clock_frequency)
> +    * RPT_ID[10:9]:  RP_FREQ_NORMAL[22:21] (high squashed_slice_clock_frequency)
> +    * RPT_ID[8:0]:   RP_FREQ_NORMAL[31:23] (squashed_unslice_clock_frequency)
> +    *
> +    * Slice/Unslice frequency values from the RP_FREQ_NORMAL register are
> +    * multiples of 16.66MHz.
> +    */
> +
> +   uint32_t unslice_freq = report[0] & 0x1ff;
> +   uint32_t slice_freq_low = (report[0] >> 25) & 0x7f;
> +   uint32_t slice_freq_high = (report[0] >> 9) & 0x3;
> +   uint32_t slice_freq = slice_freq_low | (slice_freq_high << 7);
> +
> +   *slice_freq_hz = slice_freq * 16666000ULL;
> +   *unslice_freq_hz = unslice_freq * 16666000ULL;

Thanks!  The comments are really helpful.

I'm unclear whether the RPT_ID fields exist on BDW.  Some docs seem to
indicate so, but they're really a mess.

I was also wondering if we wanted a bit more precision on the 16.66
approximation, but it's probably always going to be a bit off, and this
seems good enough.

Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180420/7d78cb5e/attachment.sig>