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... ;-) Thanks Marius _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
