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

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

[Marius Gröger]

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.

What I've tried so far:

* I tried bisecting, but I failed to spot the offending commits somehow.
My last hope is this list of experts - for me the git logs look sane,
but you guy surely have more insight.

* I tried turning on drm debug=1, but did not see anything suspicious,
especially with relation to the r600 irq handling changes.

* Currently I'm in the process of setting up systemtap to profile the
scheduling, but I'm still on the learning curve :)

I'd be most grateful for any tips and things to try to isolate this issue.

Thanks
Marius


------------------------------------------------------------------------------

--

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

[Marius Gröger]

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.

What I've tried so far:

* I tried bisecting, but I failed to spot the offending commits somehow.
My last hope is this list of experts - for me the git logs look sane,
but you guy surely have more insight.

* I tried turning on drm debug=1, but did not see anything suspicious,
especially with relation to the r600 irq handling changes.

* Currently I'm in the process of setting up systemtap to profile the
scheduling, but I'm still on the learning curve  :)

I'd be most grateful for any tips and things to try to isolate this issue.

Thanks
Marius

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

[Michel Dänzer]

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 I've tried so far:
> 
> * I tried bisecting, but I failed to spot the offending commits somehow.
> My last hope is this list of experts - for me the git logs look sane,
> but you guy surely have more insight.
> 
> * I tried turning on drm debug=1, but did not see anything suspicious,
> especially with relation to the r600 irq handling changes.
> 
> * Currently I'm in the process of setting up systemtap to profile the
> scheduling, but I'm still on the learning curve  :)
> 
> I'd be most grateful for any tips and things to try to isolate this issue.

If you have dynamic PM enabled, does disabling that help?


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Marius Gröger]

Hi Michel,

Michel Dänzer schrieb:
> 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.

Hm, ok... AFAIK MythTV tries several sync mechanisms with DRM being
preferred. I tried with OpenGL syncing but the issue remains.

> If you have dynamic PM enabled, does disabling that help?

No I don't have that enabled.

Any other ideas?

Thanks
Marius

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Marius Gröger]

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?

Marius

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Alex Deucher]

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.

Alex

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

[Marius Gröger]

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.

Thanks
Marius

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

[Alex Deucher]

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?

Alex

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

[Marius Gröger]

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... ;-)

Thanks
Marius
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Alex Deucher]

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=bc35afdb182d4c48c889fe27ba7a5d7ea0c8194d
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4fa07bf146aaee1e8409d35ab08624041c2e3867

Alex

> Thanks
> Marius
>

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

[Marius Gröger]

Am 04.06.2010 17:17, schrieb Alex Deucher:
> 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.
[...]
> Any chance you can bisect the problematic commit?

I did a second attempt at bisecting and now I'm confident it is this 
commit which broke my real-time performance in mythtv:

commit eb1f8e4f3be898df808e2dfc131099f5831d491d
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 7 06:42:51 2010 +0000

     drm/fbdev: rework output polling to be back in the core. (v4)

Having found the commit is the good news. The bad news is that this 
commit is rather large, so again I'd be depended on the experts around 
here to isolate what's going on.

Dave, would you mind giving a hand as well as the author of this commit?

Thanks
Marius

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

[James Simmons]

> > 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.

Tho not the case for MythTV on a embedded device requiring apps to use GLX 
wuld be to heavy. I would agree libdrm should be used.

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

[Marius Gröger]

Am 06.06.2010 18:47, schrieb James Simmons:
>
>>> 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.
>
> Tho not the case for MythTV on a embedded device requiring apps to use GLX
> wuld be to heavy. I would agree libdrm should be used.

I have found the cause for the glitch and just filed
http://bugs.freedesktop.org/show_bug.cgi?id=28411.

Regards
Marius

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

[Dave Airlie]

On Mon, Jun 7, 2010 at 3:52 AM, Marius Gröger
<marius.groeger@googlemail.com> wrote:
> Am 06.06.2010 18:47, schrieb James Simmons:
>>
>>>> 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.
>>
>> Tho not the case for MythTV on a embedded device requiring apps to use GLX
>> wuld be to heavy. I would agree libdrm should be used.
>
> I have found the cause for the glitch and just filed
> http://bugs.freedesktop.org/show_bug.cgi?id=28411.

Okay I can see the problem, now I have to think of a good solution,

I probably need to break down the locking a bit further which is a bit messy.

Dave.

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

[Marius Gröger]

Am 07.06.2010 00:15, wrote Dave Airlie:
> On Mon, Jun 7, 2010 at 3:52 AM, Marius Gröger
> <marius.groeger@googlemail.com>  wrote:
>> Am 06.06.2010 18:47, schrieb James Simmons:
>>>
>>>>> 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.
>>>
>>> Tho not the case for MythTV on a embedded device requiring apps to use GLX
>>> wuld be to heavy. I would agree libdrm should be used.
>>
>> I have found the cause for the glitch and just filed
>> http://bugs.freedesktop.org/show_bug.cgi?id=28411.
>
> Okay I can see the problem, now I have to think of a good solution,
>
> I probably need to break down the locking a bit further which is a bit messy.

Is there any news on this issue? I didn't notice any commits to d-r-t or 
d-n WRT this, but then again those repos aren't updated very frequently 
anyway (how come?)

Thanks T& Regards,
Marius

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

[Dave Airlie]

On Mon, Aug 2, 2010 at 8:12 PM, Marius Gröger
<marius.groeger@googlemail.com> wrote:
> Am 07.06.2010 00:15, wrote Dave Airlie:
>>
>> On Mon, Jun 7, 2010 at 3:52 AM, Marius Gröger
>> <marius.groeger@googlemail.com>  wrote:
>>>
>>> Am 06.06.2010 18:47, schrieb James Simmons:
>>>>
>>>>>> 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.
>>>>
>>>> Tho not the case for MythTV on a embedded device requiring apps to use
>>>> GLX
>>>> wuld be to heavy. I would agree libdrm should be used.
>>>
>>> I have found the cause for the glitch and just filed
>>> http://bugs.freedesktop.org/show_bug.cgi?id=28411.
>>
>> Okay I can see the problem, now I have to think of a good solution,
>>
>> I probably need to break down the locking a bit further which is a bit
>> messy.
>
> Is there any news on this issue? I didn't notice any commits to d-r-t or d-n
> WRT this, but then again those repos aren't updated very frequently anyway
> (how come?)
>

Should be fixed in 2.6.35 final, 29508eb66bfacdef324d2199eeaea31e0cdfaa29
drm/radeon/kms: drop taking lock around crtc lookup.

Generally regression fixes go via the drm-fixes tree, the other trees
get rebased/updated as patches arrive, we didn't really have much for
d-r-t this cycle.

Dave.