Bug 26641 - RV730 agp xf86-video-ati with kms poor performance
Summary: RV730 agp xf86-video-ati with kms poor performance
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R600 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 26816 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-02-18 15:46 UTC by Michał Ostrowski
Modified: 2012-09-11 17:32 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
configs and logs (22.68 KB, application/octet-stream)
2010-02-18 15:50 UTC, Michał Ostrowski
Details

Description Michał Ostrowski 2010-02-18 15:46:55 UTC
I use Radeon 4650 AGP (RV730). System: Archlinux. CPU: AMD Athlon(tm) 64 Processor 3000+

I use kernel 2.6.33 rc8 with ati kms support. I have compiled mesa and driver from git (exact compile options in attachments). I can get no more than 600fps in glxgears.

glxgears
2529 frames in 5.0 seconds = 505.756 FPS
2415 frames in 5.0 seconds = 482.971 FPS
2440 frames in 5.0 seconds = 487.853 FPS
1905 frames in 5.0 seconds = 380.890 FPS
1901 frames in 5.0 seconds = 380.119 FPS
1935 frames in 5.0 seconds = 386.888 FPS
1887 frames in 5.0 seconds = 377.399 FPS
1843 frames in 5.0 seconds = 368.464 FPS
^C

I must say, I didn't do anything when I ran glxgears. What is strange just after I startx, I get 550-600 fps. When I start a few apps (like, psi, firefox, a few urxvt terminals (nothing more is running in background except openbox and tint2) it looks like above. After some time, I have ~ 110fps (as when I'm writing this report now).

Tried also extreme tux racer. I can run it ( ~ 9fps), but it crashes after while (1024x768, rest of the options not touched).

Inside the attachment I've put all used pkgbuilds, kernel config, glxinfo, X log.

If you need any more info, please ask - I'll do my best to answer.

Regards
Comment 1 Michał Ostrowski 2010-02-18 15:50:19 UTC
Created attachment 33405 [details]
configs and logs
Comment 2 Martin Peres 2010-02-18 16:44:18 UTC
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.
Comment 3 Andy Furniss 2010-02-18 17:25:32 UTC
(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,
Comment 4 Alex Deucher 2010-02-18 17:30:43 UTC
This bug is a duplicate of this one:
http://bugzilla.kernel.org/show_bug.cgi?id=15328
Comment 5 Michał Ostrowski 2010-02-19 11:43:50 UTC
(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.
Comment 6 Tobias Jakobi 2010-02-19 14:40:54 UTC
Same card model as Martin here (and PCIe also) and also hitting this bug.
Comment 7 Tobias Jakobi 2010-02-19 14:52:29 UTC
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...
Comment 8 Tobias Jakobi 2010-02-19 16:13:09 UTC
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....
Comment 9 Alex Deucher 2010-03-09 11:38:22 UTC
*** Bug 26816 has been marked as a duplicate of this bug. ***
Comment 10 Andy Furniss 2010-03-15 05:23:09 UTC
(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.
Comment 11 Alex Deucher 2010-03-15 09:58:05 UTC
Does xf86-video-ati from git master help?  Specifically this commit:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=488c9fd8300505cc6c0c2f8f0f00849f27cc5d63
Comment 12 Andy Furniss 2010-03-15 11:15:17 UTC
(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.
Comment 13 Andy Furniss 2010-04-07 17:06:14 UTC
(In reply to comment #12)

This is fixed for me now that the ttm page allocator is in drm-radeon-testing.
Comment 14 Andy Furniss 2010-04-08 06:45:45 UTC
(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.
Comment 15 Andy Furniss 2010-04-20 04:32:09 UTC
(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.
Comment 16 Andreas Boll 2012-09-11 17:32:55 UTC
(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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.