Created attachment 42113 [details] gdb trace 2.6.37 final, intel ddx from git master, xorg xserver 1.9.3, kde 4.5.5 and mesa 7.10. There is no such problem with Mesa 7.9(.1). The problem is once for a few minutes my apps stall/freeze, cursor is moving but I can't do anything with apps. There is nothing bad in dmesg or xorg log. Mesa seem to spent a lot of time in areas around: 0x00007f317d3a5cc9 in pq_test (g=0x57af820) at program/register_allocate.c:230 230 if (j == n || g->nodes[j].in_stack) or pq_test (g=0x4966080) at program/register_allocate.c:229 229 for (j = 0; j < g->count; j++) { Attached gdb trace has few ctrl+c + continue in second half of the log. Between each continue and ctrl+c there was 3-4 second delay.
Mesa master likely improves the situation, though the real problem is probably kwin blowing out the state cache somehow. However, it's hard to tell -- you should use sysprof instead of ^C in gdb to do sampling profiling.
Created attachment 42327 [details] sysprof With mesa master it's better. There are big slowdowns instead of "freezes" now. Slowdowns are much shorter than "freezes". sysprof attached but not sure if it's ok/correct one.
I expect the problem is fixed now with the state streaming work landed. Could you confirm? (If not, I expect that a gdb breakpoint on _mesa_ProgramStringARB and _mesa_LinkShader would show the application regularly submitting new programs, which would be useful information)
I'm running 7.11 from git (20110504 at this moment) and the problem no longer occurs, so I guess it is fixed already.
thanks for confirming!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.