[PATCH 09/13] tests/intel/xe_oa: Test oa buffer sizes

Umesh Nerlige Ramappa umesh.nerlige.ramappa at intel.com
Sat Feb 22 01:12:00 UTC 2025


On Fri, Feb 21, 2025 at 04:13:31PM -0800, Dixit, Ashutosh wrote:
>On Tue, 18 Feb 2025 10:44:54 -0800, Umesh Nerlige Ramappa wrote:
>>
>
>Hi Umesh,
>
>> On Tue, Feb 18, 2025 at 10:34:53AM -0800, Dixit, Ashutosh wrote:
>> > On Fri, 14 Feb 2025 17:06:24 -0800, Umesh Nerlige Ramappa wrote:
>> >>
>> >> Introduce oa buffer size test separately. Pick a random valid buffer
>> >> size for the test.
>> >>
>> >> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa at intel.com>
>> >> ---
>> >>  tests/intel/xe_oa.c | 30 ++++++++++++++++++++++++++++++
>> >>  1 file changed, 30 insertions(+)
>> >>
>> >> diff --git a/tests/intel/xe_oa.c b/tests/intel/xe_oa.c
>> >> index 03d223df4..ee87b7338 100644
>> >> --- a/tests/intel/xe_oa.c
>> >> +++ b/tests/intel/xe_oa.c
>> >> @@ -93,6 +93,23 @@ struct accumulator {
>> >>	uint64_t deltas[MAX_RAW_OA_COUNTERS];
>> >>  };
>> >>
>> >> +struct oa_buf_size {
>> >> +	char name[12];
>> >> +	uint32_t size;
>> >> +} buf_sizes[] = {
>> >> +	{ "128K", SZ_128K },
>> >> +	{ "256K", SZ_256K },
>> >> +	{ "512K", SZ_512K },
>> >> +	{ "1M", SZ_1M },
>> >> +	{ "2M", SZ_2M },
>> >> +	{ "4M", SZ_4M },
>> >> +	{ "8M", SZ_8M },
>> >> +	{ "16M", SZ_16M },
>> >> +	{ "32M", SZ_32M },
>> >> +	{ "64M", SZ_64M },
>> >> +	{ "128M", SZ_128M },
>> >
>> > Would you have the running time for these? Hopefully not too huge for the
>> > large buffer sizes, even if we are running just one of them? And what about
>> > slower platforms?
>> >
>> > That was the reason we restricted OA buffer size to just 16 M.
>> >
>> > This is what I measured here:
>> >
>> > https://patchwork.freedesktop.org/patch/627269/?series=142128&rev=1
>> >
>> >	$ sudo ./build/tests/xe_oa --r oa-buffer-size
>> >	IGT-Version: 1.29-g724fd0b79 (x86_64) (Linux: 6.12.0-rc4+ x86_64)
>> >	Using IGT_SRANDOM=1733459091 for randomisation
>> >	Opened device: /dev/dri/card0
>> >	Starting subtest: oa-buffer-size
>> >	Starting dynamic subtest: 8MB
>> >	Dynamic subtest 8MB: SUCCESS (0.403s)
>> >	Starting dynamic subtest: 32MB
>> >	Dynamic subtest 32MB: SUCCESS (1.595s)
>> >	Starting dynamic subtest: 128MB
>> >	Dynamic subtest 128MB: SUCCESS (6.326s)
>> >	Subtest oa-buffer-size: SUCCESS (8.324s)
>>
>> I can run 128MB and see how long it takes. I guess I didn't hit the larger
>> buffers on random runs.  Technically around 30 seconds for 128MB buffer
>> with 20us period and a 256 byte report. If report is 576 bytes, then 13
>> seconds. As long as it falls within the IGT timeout period, we should be
>> good.
>
>To do a quick regression test I frequently just run the OA tests locally
>with:
>
>	sudo ./build/tests/xe_oa
>
>So I don't care how long CI takes to run the tests, but for me I want the
>each test to finish in ~3 seconds tops.
>
>Though in this case, on LNL:
>
>	$ sudo ./build/tests/xe_oa --r buffer-size
>	IGT-Version: 1.30-g71d723c60 (x86_64) (Linux: 6.13.0+ x86_64)
>	Using IGT_SRANDOM=1740181681 for randomisation
>	Opened device: /dev/dri/card0
>	Starting subtest: buffer-size
>	Starting dynamic subtest: ccs-0-128M
>	Dynamic subtest ccs-0-128M: SUCCESS (2.959s)
>	Subtest buffer-size: SUCCESS (2.959s)
>
>This seems to meet the 3 seconds criteria so it's ok.
>
>The big outlier is this one:
>
>	$ sudo ./build/tests/xe_oa --r buffer-fill
>	IGT-Version: 1.30-g71d723c60 (x86_64) (Linux: 6.13.0+ x86_64)
>	Using IGT_SRANDOM=1740182998 for randomisation
>	Opened device: /dev/dri/card0
>	Starting subtest: buffer-fill
>	Starting dynamic subtest: ccs-0
>	Dynamic subtest ccs-0: SUCCESS (24.869s)
>	Subtest buffer-fill: SUCCESS (24.869s)
>
>which is definitely not ok and would need a respin.

ok, it looks like for Xe you have reduced the test times drastically. I 
did not consider that. I was just focusing on making the tests uniform 
in terms of the exponent used.

Maybe I will just use the simulation exponent (1000ns) for the tests 
that need to run fast so their implementation stays the same.

Thanks,
Umesh

>
>Anyway I should have other comments on the patches too, so wait for my
>review comments before posting a new revision.
>
>Thanks.
>--
>Ashutosh
>
>
>>
>> >
>> >> +};
>> >> +
>> >>  /* OA unit types */
>> >>  enum {
>> >>	OAG,
>> >> @@ -305,6 +322,7 @@ static struct intel_mmio_data mmio_data;
>> >>  static igt_render_copyfunc_t render_copy;
>> >>  static uint32_t rc_width, rc_height;
>> >>  static uint32_t buffer_fill_size;
>> >> +static uint32_t num_buf_sizes;
>> >>
>> >>  static struct intel_xe_perf_metric_set *metric_set(const struct drm_xe_engine_class_instance *hwe)
>> >>  {
>> >> @@ -1094,6 +1112,7 @@ init_sys_info(void)
>> >>	rc_width = 1920;
>> >>	rc_height = 1080;
>> >>	buffer_fill_size = SZ_16M;
>> >> +	num_buf_sizes = ARRAY_SIZE(buf_sizes);
>> >>	oa_exponent_default = max_oa_exponent_for_period_lte(1000000);
>> >>
>> >>	default_oa_buffer_size = get_default_oa_buffer_size(drm_fd);
>> >> @@ -4805,6 +4824,17 @@ igt_main
>> >>		__for_one_hwe_in_oag(hwe)
>> >>			test_buffer_fill(hwe);
>> >>
>> >> +	/**
>> >> +	 * SUBTEST: buffer-size
>> >> +	 * Description: Test various OA buffer sizes
>> >> +	 */
>> >> +	igt_subtest_with_dynamic("buffer-size") {
>> >> +		long k = random() % num_buf_sizes;
>> >> +
>> >> +		__for_one_hwe_in_oag_w_arg(hwe, buf_sizes[k].name)
>> >> +			test_non_zero_reason(hwe, buf_sizes[k].size);
>> >> +	}
>> >> +
>> >>	igt_subtest_with_dynamic("non-zero-reason")
>> >>		__for_one_hwe_in_oag(hwe)
>> >>			test_non_zero_reason(hwe, 0);
>> >> --
>> >> 2.34.1
>> >>


More information about the igt-dev mailing list