| Summary: | everything stalls while mesa is doing some loops | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Arkadiusz Miskiewicz <arekm> |
| Component: | Drivers/DRI/i965 | Assignee: | Eric Anholt <eric> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | 7.10 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
gdb trace
sysprof |
||
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.
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.