[Bug 100572] [SKL dmc] Headless mode media transcoding is 20-30% slower comparing to connected monitor use case

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=100572

--- Comment #14 from Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com> ---
(In reply to Imre Deak from comment #11)
> (In reply to Tvrtko Ursulin from comment #9)
> > (In reply to Imre Deak from comment #7)
> > > (In reply to Tvrtko Ursulin from comment #6)
> > > > I tried not loading the DMC firmware and can confirm that the issue is not
> > > > present in that case.
> > > > 
> > > > Also, it is possible to reproduce this in the default kernel config (no
> > > > pinning is required) simply with igt/benchmarks/gem_latency -n 0 in which
> > > > case the perf difference between the two setups was ~8x in my testing.
> > > 
> > > One possibility is that DC6 enables deeper system level power states and
> > > this causes latency elsewhere. What are the PC state residencies shown by
> > > powertop or the kernel's tools/power/x86/turbostat when DMC is loaded and
> > > not?
> > 
> > 1. With DMC, idle system, no displays:
> > 
> > PKG is in PC2, 
> 
> PC2 vs. PC7 without DMC is weird, no idea for the reason. Normally you
> should reach PC8+ with display off, but for that you'd also need to enable
> power saving for other devices too.
> 
> > CPU is in C7, GPU is in RC6.
> 
> Was this also by booting with 'intel_idle.max_cstate=1 i915.enable_rc6=0'?
> Those should prevent C7 and RC6.. Dmitry saw the problem even with these
> settings, but would be good to double check on your side too, since RC6

I did not bother running with disabled rc6 since that does not seem to have any
effect to all this.

> would be the most logical root cause. Did you check the CPU cstate also when
> you ran with max_cstate=0?

Yeah I did check, PKG and CPU were both in top states then.

> > When looking in i915_dmc_info I can see that the "DC3 - > DC5" transition
> > counter increases exactly by one each second. "DC5 -> DC6 counter is zero".
> 
> Err, forgot to say that reading that file itself increases the counter (if
> DC states are enabled, so display is off):/ So you should sample only at the
> beginning and end of the test and deduct the increment caused by the
> sampling.
> 
> > 
> > If I now run gem_latency -n 0:
> > 
> > "DC3 -> DC5" counter starts increasing by ~2k per second.
> 
> Same here as above, in case you now sampled with higher freq.

I was sampling once per second so the ~2k per second increase still sounds
valid.

> > PKG is not any deeper states now.
> > CPU split between C2/C3/C6/C7 is approx. 42/2/10/40%.
> > GPU is 0% RC6.
> > 
> > Benchmark goes slow.
> > 
> > 2. Now I force turn on a display (echo on | 
> > tee /sys/class/drm/card0-HDMI-A-1/status).
> > 
> > "DC3 -> DC5" transition counter stops increasing.
> 
> Right, display-on keeps it in DC0.
> 
> > 
> > PKG is still in PC2, CPU in C7 and GPU in RC6.
> > 
> > Benchmark is not normal speed and while it is running PKG is not in any low
> > power states, RC6 is 0% and CPU C2/C3/C6/C7 is approx 52/0/0/25%.
> 
> Hm, so now we are constantly in DC0 and so DMC should be completely inactive
> (it only ever activates when either entering DC5 or DC6). Yet there is a
> slow-down, seemingly caused by it.
> 
> > 
> > 3. DMC not loaded, idle system, no displays
> > 
> > PKG is now in PC7 (not PC2 as above!), CPU is C7, GPU is RC6.
> > 
> > gem_latency is now normal speed with power states like above.
> > 
> > Out of curiosity I tried forcing the display on in this config. That makes
> > the PKG go to ~3% PC2, rest in PC7. Turning it off again brings it back to
> > <0.5% PC2 and the rest in PC7.
> >  
> > > What's the effect of limiting max_cstates to 0 (and having DMC loaded)?
> > 
> > No effect on benchmark speed or reported "DC3 -> DC5" transitions.
> 
> As above, did you double check if the cstate limit is really in effect?

Yep.

> > > An other problem could be that the GPU is trying to access the display,
> > > (maybe checking scan line counts or something?).
> > 
> > You mean something behind the covers or explicitly by i915?
> 
> It was just a wild guess, not sure at all if it's possible. The kernel
> shouldn't do anything while the display is off, unless you have runtime PM
> enabled (if /sys/bus/pci/devices/0000\:00\:02.0/power/control contains
> 'auto') Ville said that X does the scan line readout when rendering to the
> front buffer, but that shouldn't be the case here. Yea, could be still
> something under the hood by the HW itself, DC transitions would be an
> indication for that.

I got 'on' in /sys/bus/pci/devices/0000\:00\:02.0/power/control. And no X
running or anything. Just fbcon but no displays connected. Should I try without
fbcon perhaps?

> > > Does /sys/kernel/debug/dri/0/i915_dmc_info show any transitions during the
> > > test when DMC is loaded?
> > 
> > Yes, see above. :)
> 
> So no good idea still. One other thing to try would be to limit the package
> state to PC2 in BIOS if there is an option for that and boot with DMC; would
> show if somehow the PC7 vs. PC2 difference itself would be the cause.

Will try.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170407/a9f494cc/attachment-0001.html>