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.landwer...@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 <kenn...@whitecape.org>

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to