Bug 27434 - [rv710] low 3d perfomance in general
Summary: [rv710] low 3d perfomance in general
Status: RESOLVED WONTFIX
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R600 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-02 15:41 UTC by Andrian Nord
Modified: 2014-07-07 16:02 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (36.81 KB, application/octet-stream)
2010-04-02 15:41 UTC, Andrian Nord
Details
dmesg output (48.43 KB, text/plain)
2010-04-02 15:43 UTC, Andrian Nord
Details
xorg.conf (1.76 KB, text/plain)
2010-04-02 15:43 UTC, Andrian Nord
Details
glxinfo output (16.10 KB, text/plain)
2010-04-02 15:44 UTC, Andrian Nord
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrian Nord 2010-04-02 15:41:14 UTC
Created attachment 34633 [details]
Xorg.0.log

anholt benchmark (1600x900): 840 frames 33.3 seconds 25.2 fps 14.0/39.7/72.0/8.3 ms

After some talks on #radeon, I get that it's way too slow. Anyway, any other 3d program (like doom3) may work, but performance far beyond hardware's capabilities. I'm not talking about features now - all settings are minimal.

Other demos, including those provided into progs/demos are also showing low performance results. If any further testing will be required - I'm on it.

lspci: 01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD 4500 Series]

versions: xorg-server-1.8.0, libdrm, mesa, xf86-video-ati: git (~21:00 UTC 02.04.2010), kernel 34_rc2 from zen.git. KMS enabled.

Xorg log attached. glxinfo, dmesg and xorg.conf will follow. Info by "script" from free3d.org:
model name      : Intel(R) Core(TM)2 Duo CPU     T6600  @ 2.20GHz
cpu MHz         : 1200.000
model name      : Intel(R) Core(TM)2 Duo CPU     T6600  @ 2.20GHz
cpu MHz         : 1200.000
X.Org version: 1.8.0
  dimensions:    1600x900 pixels (423x238 millimeters)
  depth of root window:    24 planes
Mesa: Mesa 7.9-devel DEBUG build Apr  3 2010 01:46:59
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
Mesa: Initializing x86-64 optimizations
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
--
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV710 9553) 20090101  TCL DRI2
OpenGL version string: 2.0 Mesa 7.9-devel
Linux 2.6.34-rc2-zen1-nord-0.8
Mesa: Mesa 7.9-devel DEBUG build Apr  3 2010 01:46:59
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
Mesa: Initializing x86-64 optimizations
Running synchronized to the vertical refresh.  The framerate should be
approximately 1/1096764487 the monitor refresh rate.
7612 frames in 5.0 seconds = 1522.255 FPS
Comment 1 Andrian Nord 2010-04-02 15:43:06 UTC
Created attachment 34634 [details]
dmesg output
Comment 2 Andrian Nord 2010-04-02 15:43:46 UTC
Created attachment 34635 [details]
xorg.conf
Comment 3 Andrian Nord 2010-04-02 15:44:20 UTC
Created attachment 34636 [details]
glxinfo output
Comment 4 Alex Deucher 2010-10-19 19:29:58 UTC
Is this still an issue with mesa 7.9?
Comment 5 Daniel Hill 2010-12-12 21:41:46 UTC
I can confirm this happens with git on both the gallium and normal drivers
Comment 6 Stefan Dösinger 2011-09-03 13:34:57 UTC
I get very bad GPU-side performance on my Radeon X1600 GPU with r300g as well. For example, ut2004 with maxed out settings at 1440x900 runs at 5-20 fps, in very intensive fighting down to 1-2 fps. On Windows XP(same settings, GL renderer) it generally runs at 30-60 fps, in very intense fighting at 15-20.

The game is GPU limited with Mesa, the CPU utilization is about 20% on one core, the other core is idle. On Windows the game may be CPU limited - 100% CPU utilization on one core. It is also possible that the Windows driver uses busy waiting when waiting for the GPU.

etracer is runs at 30 FPS at 1440x900 and otherwise default settings, it is also GPU limited. This is unexpected as the game doesn't use any fancy fragment processing - just plain texture mapping and some environment mapping.

I'm adding this here because there are a few bug reports about performance, but none of is really useful. This bug report seems more reasonable.

Aside from performance r300g works really well. The slowness is the main issue that prevents me from "productively" using it for games.
Comment 7 Stefan Dösinger 2011-09-03 14:51:02 UTC
I installed libtxc_dxtn.so, this improved ut2004 performance. I now get 15-20 fps in most non-fighting rendering situations. That's better, but still 1/3rd of what Windows gets.

Interestingly etracer is also faster, and I don't think this game uses s3tc textures. "Who says penguins can't fly" renders at 60 fps most of the time in the canyon, with very rare drops to 30 fps for a second or two.
Comment 8 Alex Deucher 2011-09-05 19:16:01 UTC
Please open a new bug for issues with r300g.  This bug is for r6xx+ hardware which is handled by a different driver.  It's not likely the open source driver will ever be as performant as the windows driver due to the relative sizes of the development teams.  The closed source driver has several hundred developers and tons of micro-optimizations for specific situations while the open source driver has just a handful of developers.
Comment 9 Andreas Boll 2012-11-02 16:33:21 UTC
Note: classic r600 driver has been abandoned.
Please use r600g (gallium driver) instead.

Is this still an issue with a newer driver/kernel?
Comment 10 Andreas Boll 2014-07-07 16:02:00 UTC
The classic r600 driver has been abandoned long ago.
It was replaced by the Gallium driver r600g.

If you have issues with r600g please file a new bug report with component Drivers/Gallium/r600

Thanks.


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.