2010/6/4 Marius Gröger marius.groeger@googlemail.com:
Am Fri, 4 Jun 2010 11:17:12 -0400 schrieb Alex Deucher alexdeucher@gmail.com:
2010/6/4 Marius Gröger marius.groeger@googlemail.com:
Alex Deucher schrieb:
2010/6/4 Marius Gröger marius.groeger@googlemail.com:
Hi All,
Michel Dänzer schrieb:
On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote: > Hello All, > > I'm trying the top-of-trunk drm-2.6 trees (both drm-next and > drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The > primary application is mythtv which uses DRM syncing for the > frame syncronisation. Now, with the exact same userland > software I noticed the introduction of sync gliches in the > May-timeframe. The drm-radeon-testing on May 9 was still ok, > but both drm-next and drm-radeon-testing at the end of May > showed that glitch: every couple of seconds there's a very > visual hickup, especially in scroll texts. > > Apologies for such an unspecific description, and for what > almost seems like a support request for MythTV. I wouldn't post > here if I were not 100% sure it must be related with the recent > drm changes. Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs.
What about that new dri2 vsync stuff which was mentioned related to [Bug 28383]? Could the changes done for that in any way alter the timing? BTW I measured the glitches I'm experiencing and the appear to be to happen in intervals of 10 seconds. Again, all I'm changing is the kernel, and even the kernel config is the same. I'd be most grateful for any clues/hints/tips I could follow to resolve this regression.
If you have dynamic PM enabled, does disabling that help?
I checked again and there's method=profile and profile=default. Afaict this is not using dynpm, right?
Correct.
Ok so with dynpm more or less ruled out, what could have such a visible impact on the latencies? For instance, are we now more dependent (or less) on some kind of interrupt or deferred processing than 6 weeks ago?
Btw, I have HDMI audio pretty much ruled out as well.
Any chance you can bisect the problematic commit?
As I said, I already tried bisecting but failed. Perhaps I can try again and replay at least part of the log... But since we're talking about more than 120 commits I kinda was hoping to get some clues here first. Even with a tailored .config building/rebooting/testing takes ages. Well I suppose I needn't tell *you* guys... ;-)
for vsync stuff, It's probably one of these: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h... http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h...
Alex
Thanks Marius