Bug 26641

Created attachment 33405 [details]
configs and logs

Well, I have also been experiencing the same behaviour for at least one month.

I'm using an HD4470 -> rv740 with the latest radeon-testing branch.

Also, when dragging glxgears in a composited environnement, gears are slowing down to a few fps.

Tell me if you need more information.

(In reply to comment #0)

> I use kernel 2.6.33 rc8 with ati kms support.

I have a similar sounding problem on an AGP card since early Feb.

http://article.gmane.org/gmane.comp.video.dri.devel/42770

As I am running git drm-radeon-testing, to fix all I need to do is -

git revert db78e27de7e29a6db6be7caf607cf803d84094aa

I suppose you could try making a normal diff out of the revert below.

    Revert "drm/ttm: Avoid conflicting reserve_memtype during ttm_tt_set_page_caching."
    
    This reverts commit db78e27de7e29a6db6be7caf607cf803d84094aa.

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index e2123af..9c2b1cc 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -198,26 +198,17 @@ EXPORT_SYMBOL(ttm_tt_populate);
 static inline int ttm_tt_set_page_caching(struct page *p,
                                          enum ttm_caching_state c_state)
 {
-       int ret = 0;
-
        if (PageHighMem(p))
                return 0;
 
-       if (get_page_memtype(p) != -1) {
-               /* p isn't in the default caching state, set it to
-                * writeback first to free its current memtype. */
-
-               ret = set_pages_wb(p, 1);
-               if (ret)
-                       return ret;
+       switch (c_state) {
+       case tt_cached:
+               return set_pages_wb(p, 1);
+       case tt_wc:
+           return set_memory_wc((unsigned long) page_address(p), 1);
+       default:
+               return set_pages_uc(p, 1);
        }
-
-       if (c_state == tt_wc)
-               ret = set_memory_wc((unsigned long) page_address(p), 1);
-       else if (c_state == tt_uncached)
-               ret = set_pages_uc(p, 1);
-
-       return ret;
 }
 #else /* CONFIG_X86 */
 static inline int ttm_tt_set_page_caching(struct page *p,

This bug is a duplicate of this one:
http://bugzilla.kernel.org/show_bug.cgi?id=15328

(In reply to comment #3)

Thanks, this seems to work. Now I have stable ~540 fps in glxgears,

However, overall 3d performance is still rather poor: ~10fps in scorched3d minimum settings 1024x768, same in extreme tux racer. Tried q2 demo too and it seems slightly better. Though I know some cases where ppl on r6xx or even r7xx cards achieve much better performance than me.

Could it be that if my card is AGP one instead of PCIE is the cause of such poor performance (this is what I suspect)? I hope something could be done with this.

Same card model as Martin here (and PCIe also) and also hitting this bug.

Already wrote that on kernel.org, but it looks like that my problem is not really related to the DRM since it also happens when KMS is disabled.

Probably some change in mesa or libdrm...

I'm really at a loss here.

Just went back several weeks in git history with xf86-video-ati, libdrm and mesa and the problem still happens.

Furthermore I noticed that it's not only the 3D performance that collapsed. 2D is also affected. Playing a Youtube video was previously no problem at all, now the image is jerky and the system is fully loaded - most of the cycles are burned by X - something is really wrong here....

*** Bug 26816 has been marked as a duplicate of this bug. ***

(In reply to comment #9)
> *** Bug 26816 has been marked as a duplicate of this bug. ***
> 

I wasn't too sure about this when it was changed and running todays drt confirms  for me, that they are not the same issue.

comment #4 has this as a dup of

http://bugzilla.kernel.org/show_bug.cgi?id=15328

which was a regression caused by a specific commit affecting 2D & 3D perf over time, which now seems to be fixed in current drt.

http://bugs.freedesktop.org/show_bug.cgi?id=26816

was not a regression and running todays drt has actually got worse (though possibly not same xserver) - I can't even play the vid I used in that bug using x11 now, mplayer shows 125% in vo.

Does xf86-video-ati from git master help?  Specifically this commit:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=488c9fd8300505cc6c0c2f8f0f00849f27cc5d63

(In reply to comment #11)
> Does xf86-video-ati from git master help?  Specifically this commit:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=488c9fd8300505cc6c0c2f8f0f00849f27cc5d63
> 

No that doesn't help this -vo x11 issue.

It does boost xv perf so that kms now beats ums, previously kms ate a bit more cpu, but nothing like as much as this x11 issue ie. not really measurable at SD res but about 18% more 1280x720@30fps.

I retested with the last drt kernel and the figures are still the same as posted in my bug - so it's a further drt regression not xserver.

(In reply to comment #12)

This is fixed for me now that the ttm page allocator is in drm-radeon-testing.

(In reply to comment #13)
> (In reply to comment #12)
> 
> This is fixed for me now that the ttm page allocator is in drm-radeon-testing.

The further commits to drt may have regressed this again - I can't be sure as I can't run todays head, but while bisecting for -

https://bugs.freedesktop.org/show_bug.cgi?id=27536

I noticed on the "goods" close to the problematic commit that x11 putimage perf had regressed.

(In reply to comment #14)

> The further commits to drt may have regressed this again - I can't be sure as I
> can't run todays head, but while bisecting for -
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=27536
> 
> I noticed on the "goods" close to the problematic commit that x11 putimage perf
> had regressed.

That bug is fixed now and the perf with todays drt is OK, so as far as I am concerned this bug is fixed.

(In reply to comment #15)
> (In reply to comment #14)
> 
> > The further commits to drt may have regressed this again - I can't be sure as I
> > can't run todays head, but while bisecting for -
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=27536
> > 
> > I noticed on the "goods" close to the problematic commit that x11 putimage perf
> > had regressed.
> 
> That bug is fixed now and the perf with todays drt is OK, so as far as I am
> concerned this bug is fixed.

Closing.