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@xxxxxxxxx> 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@xxxxxxxxx> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@xxxxxxxxx> --- 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
