[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel

[bugzilla-daemon at freedesktop.org]

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

--- Comment #40 from Ilija Hadzic <ihadzic at research.bell-labs.com> 2011-08-18 11:23:12 PDT ---
(In reply to comment #38)
> (In reply to comment #36 and #37)
> 
> If I launch glxgears the FPS is 60/59.
> When desktop effects are active and repeatedly minimize and unminimize a window
> the FPS drops to 15 while with the old kernel before the patch it dropped to
> 30/25 and was better.
> This can be seen even by eye.
> What can I do to improve this situation?

60/59 is OK, one frame plus minus is just a rounding effect when glxgears
calculates the frame rate. So based on everything you said, I think that there
is no bug here, that it's just that your system can't keep up when you
turn on desktop effects. The root cause could be totally unrelated to
graphics subsystem.

Some explanation. Every graphics application (glxgears, KDE with desktop
effects your favorite game) is a loop that looks something like this:

while (1) {
  // do something related to application
  this();
  that();

  // dump some OpenGL commands on GPU
  glThis();
  glThat();

  // swap buffers
  glXSwapBuffers();

}

When vblank is turned on, the process will block waiting for the next vblank.
If you are running KDE with desktop effects and glxgears at the same time, 
these are separate processes that OS is scheduling. If both of them
can do their this(); and that(); in time that is much shorter than 
1/screen_refresh_rate, then you see the FPS equal to the refresh rate 
and it's steady. If one process executes this() and that() for too long,
then it misses the vblank and you see reduced (and maybe erratic) frame 
rate. Notie that max. time per loop iteration must be shorter that the
frame interval time. If it's somethimes shorter and sometimes longer
then vblanks are sometimes missed, sometimes not.

So with newer kernel vblanks work correctly, DDX uses them, but this() 
and that() in your KDE is unfortunately too slow (probably on the
boundary of frame interval). Note that glxgears is a different process 
whose this() and that() are doing almost nothing so it can top at much 
higher rate (probably determined by the rate at which the GPU can 
process its rendering command). KDE on the other hand is probably limited
by what the host is doing.

Now when you removed my patch from the kernel (or when you were running
2.6.38 kernel) but you still used the latest DDX, the DDX just decided to
not attempt the synchronization because it was missing the kernel capability
(handling of CRTCs > 1 .... your problem had nothing to do with that, but
missing capability was the reason for DDX to run unsynchronized). In this
situation both KDE and glxgears became tight loops with no wait
at the swap call. glxgears topped at 2000-something iterations of the loop
per second and that was the reported frame rate, while KDE topped at much
lower rate (100-something). Visually, that looked better for you because
you didn't have the effect of sometimes completing the loop iteration in
time and sometimes not (and thus missing the vblanks).

So the root cause is that you have to find out what is causing KDE to
slow down. It can be many reasons from a simply slow machine to 
some I/O device monopolizing the bus or some process causing KDE
to stall. 

You may want to try selectively disabling some effects and
until you get to the subset of effects that leave you with an acceptable
performance, but you should also search for causes outside the graphics
subsystem.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.