r6xx 3D games

[Zajec]

Yeah, the drivers are written for real world apps that do a lot of drawing in each frame, ie the drawing code gets more attention than the "once per frame" code.

The glxgears program draws so little each frame that you end up measuring the performance of the "once per frame" code rather than the drawing code -- so the correlation between glxgears performance and real world application performance is weak at best.

That's why the devs make rude comments about glxgears being used as a benchmark for anything other than buffer-flipping. Any frame rate faster than your display refresh rate is largely wasted anyways.

Ups, that's not really want I meant.

I know exactly glxgears is winner of the worst benchmark

I meant maybe whole Mesa is not written to achieve more than 60fps? Don't know much about 3D however, that's why I ask.

[bridgman]

That was the question I answered

Put differently, the mesa code has no trouble running at faster than 60 hz (unless you have sync-to-vblank enabled and have a 60 hz display, of course) but nobody really cares if it runs a trivial app at 770 fps or 6000 fps since displays max out around 120 fps anyways.

Putting effort into making the per-frame code go faster would only make a real difference on trivial apps with very high frame rates, which don't correlate well with real world performance anyways.

[Zajec]

Thanks for re-explaining It seems I try to understand too much things like for one day

[pingufunkybeat]

If the frame rate doesn't change much with resolution that means you're either CPU bound or limited by the driver's ability to overlap GPU and CPU processing.

Thanks for the reply. It is definitely not CPU bound in this case, on a Phenom II quad. I could probably render OpenArena in software

Are you running with KMS ? If so the new memory manager code is probably introducing some frame rate variations, but that will improve over time.

Yes, I'm running with KMS, which is when the freezes started appearing. Updates to drm-next have improved the situation, so I guess that KMS does play a role in all of this.

but nobody really cares if it runs a trivial app at 770 fps or 6000 fps since displays max out around 120 fps anyways.

Yes and no.

Due to historical reasons, you cannot move properly in games based on the Quake3 engine (and older) unless you have (steady) 125 fps. There are fixes for this, but they are still not commonplace.

It is also very important to have a stable frame rate. Which means that you must be able to render more than 60 per second in most situations, so you can still keep this rate during very complex scenes.

[agd5f]

Yes, I'm running with KMS, which is when the freezes started appearing. Updates to drm-next have improved the situation, so I guess that KMS does play a role in all of this.

The memory manager is probably the largest factor. It's not currently very well optimized. Placement of buffers and when to migrate (gart vs. vram vs. unmappable vram) can make a huge difference for performance. Right now we are just getting the infrastructure in place and making it stable. After that, we need to profile usage patterns and tune the memory manager accordingly.

[bridgman]

Due to historical reasons, you cannot move properly in games based on the Quake3 engine (and older) unless you have (steady) 125 fps. There are fixes for this, but they are still not commonplace.

It is also very important to have a stable frame rate. Which means that you must be able to render more than 60 per second in most situations, so you can still keep this rate during very complex scenes.

I picked the numbers carefully. Getting decent frame rates for games and other apps is a concern, but getting thousands of fps is not.

[Wielkie G]

Can I ask where newest bleeding-edge DRM r600 module I can compile and test is? I'm using ubuntu lucid kernel (based on 2.6.32-rc7 AFAIK) and mesa master but I have some problems with 3d. Well... 3d works great, but framerates aren't high. Stable 30-40 fps wouldn't be a problem, but my fps drops from time to time perfectly killing whole gaming experience.
If there is any code that would improve this, I can test it.
Thanks

[netkas]

Still can't get etracer to work, it complains about missing visuals.

Anyone had a luck with it ?

[legume]

Thanks for the reply. It is definitely not CPU bound in this case, on a Phenom II quad. I could probably render OpenArena in software

Just for laughs, what do you get with LIBGL_ALWAYS_SOFTWARE=1 :-)

Due to historical reasons, you cannot move properly in games based on the Quake3 engine (and older) unless you have (steady) 125 fps. There are fixes for this, but they are still not commonplace.

Just in case you didn't already tweak it com_maxfps defaults to 85 in OA (apart from timedemos)

I haven't seen any glitching on OA with my setup. With the current version the bloom kills fps, but I can use every thing else on/up @ 1280x1024 without issue.

I get 57fps with anholt demo on rv670 with Athlon XP 2500 @ 2.1GHz.

Maybe the glitching is due to other things running - I saw a bit on glxgears when I last tried a F12 beta KDE live CD.

[pingufunkybeat]

Is there an ETA on fixing the openarena darkness bug?

It's been extremely dark for a few weeks now.

Does anyone know a workaround?