[Bug 81682] [snb] Frequent framerate drops

[bugzilla-daemon at freedesktop.org]

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

--- Comment #11 from Chris Wilson <chris at chris-wilson.co.uk> ---
(In reply to comment #8)
> (In reply to comment #7)
> > That's different to what I was expecting. I thought that the gpufreq would
> > drop, but the game would still be struggling to render. 
> 
> Maybe I'm misunderstanding, but that is what I'm seeing - the gpufreq drops
> to minimum, and the framerate drops with it. Both seem to recover at the
> same time too. It's not just the game either - the whole desktop (both
> monitors, and multiple workspaces) become very jerky too. Or do you mean
> complete hangs when you say "struggling to render"?

What I was expecting for a normal thermal throttling issue would be that the
actual GPU frequency would be much less than the requested GPU frequency, and
the GPU would stay busy and there remain lots of commands being sent. In you
case, both the requested frequency and busyness of the GPU drop to nearly zero
(but not actually zero). That suggests the system is stalling. Can you grab a
photo of the overlay during the stall? What I am looking for this time is
whether it is recording long waits and the status of rc6 during that period.
That the cpu goes up during that time is interesting.

> > Now, the next challenge is to grap a perf profile from the good/bad periods.
> > (That's the type of integration that we want into the GPU monitoring tools,
> > but we don't have today.)
> 
> Do you have any docs I can follow on how to do that manually then, since
> it's not already in the tools?

Go to your kernel source, linux/tools/perf and run make. You can try "make
prefix=/usr/local install" (iirc). If you find all of the extras it asks for
(most importantly libunwind and libdw/libelf) when you run "./perf top" you
will see what functions are taking the most cpu time. The tricky part is that
you want to know this during the stall. I would suggest on a second computer
(or smartphone) to log in and run "sudo perf record -g -a sleep 2" during the
stall.

(In reply to comment #10)
> I've just noticed slightly different behaviour in the gpu overlay for the
> game I'm really interested in fixing (Path of Exile, which is mostly
> rendered on the nVidia card and shipped to the Intel display via the Primus
> VirtualGL layer).
> 
> In this case, the gpufreq always remains constant, around 650Mhz, even when
> the frame rate is fine. It's the power consumption that changes when the fps
> drops - it's typically idling around 600mW, but during an fps drop, the
> power consumption drops to 200mW. No idea how to interpret that, but it
> seemed like relevant data, so there it is.

Again, that seems like the system just stop sending lots of frames to show. Do
you see a noticeable fluctuation in CPU activity during time as well? Could you
also watch powertop and see how cpufreq fluctuates? I guess that is something I
could incorporate into the overlay...

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