<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>