Glitch in newer drm-next/drm-radeon-testing

[Alex Deucher]

2010/6/4 Marius Gröger <marius.groeger at googlemail.com>:
> Am Fri, 4 Jun 2010 11:17:12 -0400
> schrieb Alex Deucher <alexdeucher at gmail.com>:
>
>> 2010/6/4 Marius Gröger <marius.groeger at googlemail.com>:
>> > Alex Deucher schrieb:
>> >> 2010/6/4 Marius Gröger <marius.groeger at 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=bc35afdb182d4c48c889fe27ba7a5d7ea0c8194d
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4fa07bf146aaee1e8409d35ab08624041c2e3867

Alex

> Thanks
> Marius
>