<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - 3% perf drop in GfxBench Manhattan 3.0, 3.1 and CarChase test-cases"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111090#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - 3% perf drop in GfxBench Manhattan 3.0, 3.1 and CarChase test-cases"
href="https://bugs.freedesktop.org/show_bug.cgi?id=111090">bug 111090</a>
from <span class="vcard"><a class="email" href="mailto:eero.t.tamminen@intel.com" title="Eero Tamminen <eero.t.tamminen@intel.com>"> <span class="fn">Eero Tamminen</span></a>
</span></b>
<pre>Lakshmi, although you marked this as BXT, there was some impact visible also on
KBL GT3e. I don't think issue is BXT specific, it's visibility just depends on
relative CPU/GPU/bandwidth balance, not absolute performance, and/or how TDP
limited the device is.
(In reply to Chris Wilson from <a href="show_bug.cgi?id=111090#c1">comment #1</a>)
<span class="quote">> drm/i915/execlists: Minimalistic timeslicing</span >
...
<span class="quote">> is at least one intentional change in the scheduling that may interfere with
> throughput tests (like gfxbench) in the presence of third parties (X) also
> trying to render.</span >
All the impacted tests are complex/heavy ones, and they run in fullscreen under
Unity which handles fullscreen properly (unlike Gnome [1]) and disables
compositing. I.e. there's only single process rendering during these
benchmarks.
(In reply to Chris Wilson from <a href="show_bug.cgi?id=111090#c2">comment #2</a>)
<span class="quote">> I would say the biggest potential impact there is:
> drm/i915: Move GEM object domain management from struct_mutex to local
> drm/i915: Drop the deferred active reference
>
> Removing struct_mutex should have been an improvement (reducing lock
> contention, and at worse not making it any worse), so the extra burden of
> active reference tracking?</span >
In case it helps, these tests have hundreds of drawcalls per frame and don't
have a any single bottleneck, bottleneck can change many times during frame.
Unlike the other benchmarks I'm running, the most impacted Manhattan tests use
UBOs and transform feedback.
What about drm-tip non-i915 code changes from upstream rebases? Test machines
use P-state power management mode and GPU benchmarks on TDP-limited devices
could be impacted also by non-i915 kernel changes.
[1] <a href="https://gitlab.gnome.org/GNOME/mutter/issues/60">https://gitlab.gnome.org/GNOME/mutter/issues/60</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>