[Intel-gfx] [PATCH i-g-t 5/5] tests/perf_pmu: Tests for i915 PMU API

[Tvrtko Ursulin]

On 18/09/2017 22:18, Rogozhkin, Dmitry V wrote:
> Did you try tests on the system with 2 VDBOX engines? On my side 2 tests
> are failing on SKL GT4e NUC:

Nope.

> (perf_pmu:5414) CRITICAL: Test assertion failure function
> busy_check_all, file perf_pmu.c:164:
> (perf_pmu:5414) CRITICAL: Failed assertion: (double)(val[i]) <= (1.0 +
> tolerance) * (double)0.0f && (double)(val[i]) >= (1.0 - tolerance) *
> (double)0.0f
> (perf_pmu:5414) CRITICAL: 'val[i]' != '0.0f' (499984960.000000 not
> within 2.000000% tolerance of 0.000000)
> Subtest two-busy-check-all-bsd: FAIL (0.501s)
> 
> (perf_pmu:5414) CRITICAL: Test assertion failure function
> two_busy_check_all, file perf_pmu.c:221:
> (perf_pmu:5414) CRITICAL: Failed assertion: (double)(val[i]) <= (1.0 +
> tolerance) * (double)0.0f && (double)(val[i]) >= (1.0 - tolerance) *
> (double)0.0f
> (perf_pmu:5414) CRITICAL: 'val[i]' != '0.0f' (499940146.000000 not
> within 2.000000% tolerance of 0.000000)
> Subtest two-busy-check-all-bsd1: FAIL (0.501s)
> 
> I am trying to speculate on the reasons below.
> 
> 
> On Mon, 2017-09-18 at 12:38 +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>
>> A bunch of tests for the new i915 PMU feature.
>>
>> Parts of the code were initialy sketched by Dmitry Rogozhkin.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>> Cc: Chris Wilson <chris at chris-wilson.co.uk>
>> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin at intel.com>
>> ---
>>   lib/igt_gt.c           |  23 +-
>>   lib/igt_gt.h           |   8 +
>>   tests/Makefile.sources |   1 +
>>   tests/perf_pmu.c       | 713 +++++++++++++++++++++++++++++++++++++++++++++++++
>>   4 files changed, 738 insertions(+), 7 deletions(-)
>>   create mode 100644 tests/perf_pmu.c
>>
>> diff --git a/lib/igt_gt.c b/lib/igt_gt.c
>> index b3f3b3809eee..102cc2841feb 100644
>> --- a/lib/igt_gt.c
>> +++ b/lib/igt_gt.c
>> @@ -537,14 +537,23 @@ unsigned intel_detect_and_clear_missed_interrupts(int fd)
>>   	return missed;
>>   }
>>   
>> +enum drm_i915_gem_engine_class {
>> +	I915_ENGINE_CLASS_OTHER = 0,
>> +	I915_ENGINE_CLASS_RENDER = 1,
>> +	I915_ENGINE_CLASS_COPY = 2,
>> +	I915_ENGINE_CLASS_VIDEO = 3,
>> +	I915_ENGINE_CLASS_VIDEO_ENHANCE = 4,
>> +	I915_ENGINE_CLASS_MAX /* non-ABI */
>> +};
>> +
>>   const struct intel_execution_engine intel_execution_engines[] = {
>> -	{ "default", NULL, 0, 0 },
>> -	{ "render", "rcs0", I915_EXEC_RENDER, 0 },
>> -	{ "bsd", "vcs0", I915_EXEC_BSD, 0 },
>> -	{ "bsd1", "vcs0", I915_EXEC_BSD, 1<<13 /*I915_EXEC_BSD_RING1*/ },
>> -	{ "bsd2", "vcs1", I915_EXEC_BSD, 2<<13 /*I915_EXEC_BSD_RING2*/ },
>> -	{ "blt", "bcs0", I915_EXEC_BLT, 0 },
>> -	{ "vebox", "vecs0", I915_EXEC_VEBOX, 0 },
>> +	{ "default", NULL, -1, -1, 0, 0 },
>> +	{ "render", "rcs0", I915_ENGINE_CLASS_RENDER, 0, I915_EXEC_RENDER, 0 },
>> +	{ "bsd", "vcs0", I915_ENGINE_CLASS_VIDEO, 0, I915_EXEC_BSD, 0 },
> With such definition, we will probably detect "bsd" as an engine (as
> well as "bsd1" and "bsd2"), right? As a result, we will run
> two-busy-check-all-bsd for it and according to defined flags we will
> submit workloads to _both_ vcs0 and vcs1 evenly following i915 KMD
> dispatching. Thus, the two-busy-check-all-bsd will fail since it will
> detect a load on 3 engines (rcs0, vcs0, vcs1) instead of 2.
> 
> I am not quite sure why two-busy-check-all-bsd1 fails as well on my
> side? or rather, why it did not fail on your side as well? The only
> explanation I see is that the test thinks "bsd" and "bsd1" are separate
> engines, and, thus, count them as 2. But that should fail on single
> VDBOX system as well... hm...

What makes it fail on GT3+ parts is the fact I915_EXEC_BSD gets 
round-robinned per context.

I need to come up with an elegant solution in the world where we started 
using engine class/instance concepts but don't yet have the 
class-instance execbuf...

Regards,

Tvrtko