public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>,
	"tursulin@ursulin.net" <tursulin@ursulin.net>
Cc: "Intel-gfx@lists.freedesktop.org" <Intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH i-g-t 5/5] tests/perf_pmu: Tests for i915 PMU API
Date: Tue, 19 Sep 2017 09:19:53 +0100	[thread overview]
Message-ID: <8614ab63-5029-8193-eaf5-f73b01dcce50@linux.intel.com> (raw)
In-Reply-To: <1505740588.6405.10.camel@intel.com>


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@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@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-09-19  8:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-18 11:38 [PATCH i-g-t 0/5] IGT PMU support Tvrtko Ursulin
2017-09-18 11:38 ` [PATCH i-g-t 1/5] intel-gpu-overlay: Move local perf implementation to a library Tvrtko Ursulin
2017-09-18 11:38 ` [PATCH i-g-t 2/5] intel-gpu-overlay: Consolidate perf PMU access to library Tvrtko Ursulin
2017-09-18 11:38 ` [PATCH i-g-t 3/5] intel-gpu-overlay: Fix interrupts PMU readout Tvrtko Ursulin
2017-09-18 11:38 ` [PATCH i-g-t 4/5] intel-gpu-overlay: Catch-up to new i915 PMU Tvrtko Ursulin
2017-09-18 11:38 ` [PATCH i-g-t 5/5] tests/perf_pmu: Tests for i915 PMU API Tvrtko Ursulin
2017-09-18 13:17   ` Chris Wilson
2017-09-19  8:37     ` Tvrtko Ursulin
2017-09-19  9:58       ` Chris Wilson
2017-09-18 21:18   ` Rogozhkin, Dmitry V
2017-09-19  8:19     ` Tvrtko Ursulin [this message]
2017-09-20 16:12   ` [PATCH v2 " Tvrtko Ursulin
2017-09-18 18:16 ` ✓ Fi.CI.BAT: success for IGT PMU support (rev2) Patchwork
2017-09-19  9:44 ` ✓ Fi.CI.IGT: " Patchwork
2017-09-20 16:52 ` ✗ Fi.CI.BAT: warning for IGT PMU support (rev3) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8614ab63-5029-8193-eaf5-f73b01dcce50@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=dmitry.v.rogozhkin@intel.com \
    --cc=tursulin@ursulin.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox