[PATCH 06/16] drm/xe/oa/uapi: Define and parse OA stream properties
Lionel Landwerlin
lionel.g.landwerlin at intel.com
Fri Feb 9 06:25:40 UTC 2024
On 09/02/2024 00:26, Dixit, Ashutosh wrote:
> On Thu, 08 Feb 2024 13:40:29 -0800, Lionel Landwerlin wrote:
>
> Hi Lionel,
>
>> +
>> + /** @DRM_XE_OA_PROPERTY_OA_FORMAT: Perf counter report format */
>> + DRM_XE_OA_PROPERTY_OA_FORMAT,
>> + /**
>> + * OA_FORMAT's are specified the same way as in Bspec, in terms of
>> + * the following quantities: a. enum @drm_xe_oa_format_type
>> + * b. Counter select c. Counter size and d. BC report
>> + */
>> +#define DRM_XE_OA_FORMAT_MASK_FMT_TYPE (0xff << 0)
>> +#define DRM_XE_OA_FORMAT_MASK_COUNTER_SEL (0xff << 8)
>> +#define DRM_XE_OA_FORMAT_MASK_COUNTER_SIZE (0xff << 16)
>> +#define DRM_XE_OA_FORMAT_MASK_BC_REPORT (0xff << 24)
>>
>> People outside of Intel don't have access to the BSpec.
> Hmm, I was assuming Bspec is public, at least parts of it. Since we keep
> dropping Bspec references in patch commit messages?
>
>> And since there is no page number either
> Page numbers are in the commit message, but you are right, they should be
> added here.
>
>> , it would just be easier for everybody to say :
>>
>> "Refer to the oa_formats array in drivers/gpu/drm/xe/xe_oa.c"
> Umesh, what do you think about this? I don't like the idea too much, of
> referring to the internal implementation in the uapi, but if Bspec is not
> public, and we want to keep this uapi, we'll probably need to do this.
>
> Also, we are directly returning the oa_status register in response to
> DRM_XE_PERF_IOCTL_STATUS ioctl (see 'struct drm_xe_oa_stream_status'), so
> that also needs access to Bspec. But there I think we can just document the
> relevant bits in xe_drm.h.
What got me confused is the BC field, which I expected would take some
non-zero value so Gfx8+ formats (since some of them has B/C counters).
But actually it's zero in xe_oa.c
-Lionel
>
> Thanks.
> --
> Ashutosh
More information about the Intel-xe
mailing list