2010/6/4 Marius Gröger <marius.groeger@xxxxxxxxxxxxxx>: > Am Fri, 4 Jun 2010 11:17:12 -0400 > schrieb Alex Deucher <alexdeucher@xxxxxxxxx>: > >> 2010/6/4 Marius Gröger <marius.groeger@xxxxxxxxxxxxxx>: >> > Alex Deucher schrieb: >> >> 2010/6/4 Marius Gröger <marius.groeger@xxxxxxxxxxxxxx>: >> >>> 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=bc35afdb182d4c48c889fe27ba7a5d7ea0c8194d http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4fa07bf146aaee1e8409d35ab08624041c2e3867 Alex > Thanks > Marius > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
