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

Alex Deucher alexdeucher at gmail.com
Fri Jun 4 08:17:12 PDT 2010


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?

Alex


More information about the dri-devel mailing list