Announcement

**Nille** · 23 March 2009, 02:56 AM

Looks Like the Driver Limit the max fps to the Hz vom your display.

http://en.wikipedia.org/wiki/Vertical_synchronization

**Saist** · 23 March 2009, 04:43 AM

... glxgears is not a benchmark.

do a quick search for the terms: glxgears bridgman sitehoronix.com/forums

and you'll get posts like this : http://www.phoronix.com/forums/showp...16&postcount=4

The glxgears program is so far removed from a typical application that it's barely worth running other than making sure you have some kind of 3D support. I don't think your glxgears numbers sound unreasonable.

or this one : http://www.phoronix.com/forums/showp...7&postcount=41

Right. The glxgears program uses only fixed-function graphics (no shaders), and draws shaded triangles with no textures. Between shaders and textures that's maybe between 80% of a modern GPU sitting idle. Vertex shaders get used to emulate the fixed-function transform and lighting, but that's about it. The only block that works hard is the ROP/RBE, ie the part that handles depth compare (Z-buffer) and writes pixels into video memory.

Even worse, since older chips used relatively more of their silicon area for ROP/RBE than new chips, it's not unusual for an old GPU to outperform a new GPU on glxgears.

Next, do a search for the terms: glxgears is not a benchmark

and you'll get results like this: http://wiki.cchtml.com/index.php/Glx...ot_a_Benchmark

glxgears is an OpenGL program that reports FPS (frames per second) numbers. However, it is a very limited 'test'. Unlike most modern 3D games glxgears:

* has an extremely low vertex/polygon count
* does no texturing at all
* only simple, flat shading is used (except inside the hole in each gear is simple smooth shading)
* all vertex data is stored in a display list, so almost nothing passes between host CPU and video card once rendering is started. This mostly implies video card fill rate is limited. But, see next point.
* the default window size is 300x300, a large part of which is not even rendered into, so it's not even a good fill rate test
* the entire render step consists of only 21 OpenGL functions calls, of which only 6 are unique. This is not a very good OpenGL API stress test. Something like glean would be better.

So to summarize, glxgears only tests a small part of what you typically see in a 3D game. You could have glxgears FPS performance increase, but your 3D game performance decrease. Likewise, you could have glxgears performance decrease and your 3D game performance increase.

and this one : http://qa-rockstar.livejournal.com/7869.html

One interesting fact came out of yesterday's Intel KMS Test Day. Everyone noticed that glxgears is much slower under KMS/DRI2 than it was before (e.g. in Fedora 9 or 10). A typical result was ~1000FPS in F10, but only ~440FPS in Rawhide. So what's changed?

Here's the deal, as best as I understand it (thanks to krh/halfline/ajax for trying to explain it to me): glxgears is rendering an insanely simple scene - so simple that the actual 3D rendering time is basically zero. So the only thing glxgears really tests is the performance of glXSwapBuffers() - basically, how fast we can push render buffers into the card. This operation is slower with DRI2, but - roughly speaking - unless it was an order of magnitude slower (e.g. glxgears drops from 1000FPS to under 100FPS) it wouldn't make any real difference.

So if you're going to be comparing "3D performance" - please, don't bother with glxgears. ajax has suggested a couple of things that might make better benchmarks:

* The mesa-demos package has a few useful things - teapot in particular is nicely simple.
* sierpinski3d and glblur from xscreensaver-gl-extras also work well.
* extremetuxracer is, in my opinion, the most fun way to benchmark 3D.

If you see major (100% or more) performance differences between KMS and non-KMS in those apps, it's probably worth investigating further.

Take the advice of the people writing the drivers. Don't use glxgears to determine the speed of your rendering.

**nascentmind** · 23 March 2009, 04:59 AM

I understand that glxgears is not a benchmarking tool. I had done some tests and it was running 1000fps and suddenly after some days not sure whether it was some updates or removing the effects from kde the frame rates drops. I check even amarok visualization and it becomes sluggish after i keep atleast 10 visualizations open. Also the whole of kde feels sluggish with/without effects. Also if i open glxgears and glxheads the cpu usage jumps to 100% on one of my cores of my quad core.

Nille: How did you find out that the driver is limiting because of the vertical sync?

**nascentmind** · 23 March 2009, 12:03 PM

I tried Unigine and I am getting 15 fps. Something is seriously wrong.

**bridgman** · 23 March 2009, 01:05 PM

I don't remember the details but my recollection is that the Unigine demo is *very* demanding and did result in some pretty slow frame rates. It depends on the specific demo though... a lot of people are reporting frame rates lower than yours (albeit with slower cards) on the Tropics demo, for example.

What resolution are you running at, and which demo ?

**nascentmind** · 23 March 2009, 03:53 PM

Here are the benchmarks.

Code:

Binary:
  Linux 32bit GCC 4.1.2 Release Oct 29 2008
  Operating system:
  Linux 2.6.27-14-generic x86_64
  CPU model:
  Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz
  CPU flags:
  2333MHz MMX SSE SSE2 SSE3 HT
  GPU model:
  ATI Radeon HD 4670 2.1.8494 Release 512Mb
  Settings
Render:
  opengl
  Mode:
  1024x768 6xAA fullscreen
  Shaders:
  high
  Textures:
  high
  Filter:
  trilinear
  Anisotropy:
  16x
  Occlusion:
  enabled
  Reflection:
  enabled
  Refraction:
  enabled
  Volumetric:
  enabled

**cutterjohn** · 24 March 2009, 12:44 PM

fgl_clxgears, looks like you have vsync enabled, so it's limiting FPS to the refresh rate of the panel, 60Hz = 60FPS.

Code:

aurelius:~$ fgl_glxgears 
Using GLX_SGIX_pbuffer
13021 frames in 5.0 seconds = 2604.200 FPS
14333 frames in 5.0 seconds = 2866.600 FPS
14182 frames in 5.0 seconds = 2836.400 FPS

which is what I get with the 4850 mobile + P8600, 64b Ubuntu 8.10 + cat 9.2.

I briefly ran unigine tropics demo @ 1280x1024, but haven't had a chance to really let it complete run and save the data, but from observations I had a low FPS of 6FPS w/lots of trees/lightsource and a max of 60 FPS. I just had left everything at default values. I'd hazard that the avg would've been c. 30FPS, but I'll try to run the complete demo as a bench later. (I noticed that when I exited from it, that it failed to correctly reset desktop res to 1680x1050... annoying.

**nascentmind** · 24 March 2009, 03:31 PM

I disabled it using ati catalyst center. Also is vsync important for LCDS? I have a dell 21inch lcd screen (Dell S2209W).

Code:

Using GLX_SGIX_pbuffer
2771 frames in 5.0 seconds = 554.200 FPS
2555 frames in 5.0 seconds = 511.000 FPS
2772 frames in 5.0 seconds = 554.400 FPS

Announcement

Very low framerates with ATI radeon 4670hd card.

Very low framerates with ATI radeon 4670hd card.

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment