https://bugs.freedesktop.org/show_bug.cgi?id=39202 --- Comment #40 from Ilija Hadzic <ihadzic@xxxxxxxxxxxxxxxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
