[NEEDS INFO] Fps drops [xonotic-git][mesa-r600g-git]

Hey, Guys. I do not follow this forum too much (so sorry if similar problem has been reported) but wanted to ask if there is some known explanation to my problem: here, playing xonotic from git on Linux, using mesa drivers with a HD 5650 M card, i get really inconstant fps in all maps I tried. With effects set to Normal, I can go from near 100fps to less then 10fps depending of the part of the map I am or where I am looking to. I got the impression that this drops happen when I look to the bots moving in the map (the more bots, the bigger the drop), but I'm not 100% sure that its the only case.

So, I wanted to ask: people with proprietary drivers face this same issue with xonotic-git (or the release version) too, or mayber there's some effect that mesa doesn't handle well ? If the second is valid, which is the specific effect that I should verify ?

Since now, thanks for your attention and sorry for my possibly bad English (not my native language)

Well, everything that moves on your screen, makes your fps drop. Looking to a wall or the ground you should always get the highest fps. And bots are absolutely fps-killers. Also note that the git version will always run at lower fps than other builds, due to uncompressed textures etc.

So there is not necesarilly a problem with the game, but there still could be one.

Can you give some more specs of your system and what software you are running? Is it a recent version of Mesa?

You could try the Big Benchmark and see what results it gives across all settings:
ttp://forums.xonotic.org/showthread.php?tid=2562

This just gives some numbers to compare with.

You might want to try enabling texture comrpession in mesa, it could help:

Code:

export force_s3tc_enable=true

If you reduce the effects down to Medium settings do you get a massive improvement?

Biggest fps killers in Xonotic:

• Having bloom enabled when it's really overdone on maps (Sandstorm is a good example);
  
• Realtime world lighting being on when it is abused on some maps (Newtonian Nightmare);
  
• DECALS ON MODELS! ARRGGHHH! I think it's broken;
  
• Reflections enabled when on some maps where's the quite a lot of water (Courtfun);
  
• Having lots of bots on a map (especially when they're using weapons like rocket launchers or crylinks);
  
• Maps in general like Mental Gap Beta 2 are all exposed so you can see the entirety of the map at one given moment (unless you're looking at the floor or whatever).
  

I usually juggle between bloom, realtime world lighting and reflections and I've been doing that for a while. I always leave decals on models off and if I play with bots I tend to play against no more than 7 bots at a time.

Can you give some more specs of your system and what software you are running? Is it a recent version of Mesa?

You could try the Big Benchmark and see what results it gives across all settings:
ttp://forums.xonotic.org/showthread.php?tid=2562

This just gives some numbers to compare with.

You might want to try enabling texture comrpession in mesa, it could help:

Code:

export force_s3tc_enable=true

If you reduce the effects down to Medium settings do you get a massive improvement?

First, thanks to you both for the quick answer.

I'm playing in a HP notebook using Turion II N530 CPU (2,5 Ghz), Radeon HD 5650 Mobile graphics card (1gb VRAM), and 8 gb of RAM (Corsair, 1333Mhz). Mesa is from git master (future mesa 9.1)

Well, I have libtxc_dxtn installed, so I think I'm using texture compression when its possible, but since xonotic-git uses uncompressed textures, does this export line you suggested change something ? (I got the impression that some maps, like afterslime, improved, but can be an placebo effect)

Reducing effects to Medium really helped a lot. In Facility123 map by Cortez, there was areas when fps droped from 100+ to 6 with high settings, and the min fps I had in medium settings was near 60

Well, I have libtxc_dxtn installed, so I think I'm using texture compression when its possible,

With the lib installed it doesn't always work directly. For intellectual property reasons most distros keep it disabled. If texture compression is not working you get this line in the console:
ERROR: Texture compression is required but not supported.

but since xonotic-git uses uncompressed textures, does this export line you suggested change something ? (I got the impression that some maps, like afterslime, improved, but can be an placebo effect)

The Git version uses textures which are stored on disk uncompressed but this is not the same as texture compression in memory. Enabling texture compression will always greatly improve load times but performance can be better or not, it varies.

Reducing effects to Medium really helped a lot. In Facility123 map by Cortez, there was areas when fps droped from 100+ to 6 with high settings, and the min fps I had in medium settings was near 60

The differences between normal and medium are pretty small. Normal maps, gloss maps, deluxe maps, geometry detail and skeletal damage are the only changes. Now go through and try each of these things independently and see where the performance hit comes from. It may mean that one feature or other makes things worse.

Normal is the first level that requires OpenGL 2.0 to support all features and this is more likely to fall down with Mesa.

Thanks a lot for the answers, I'll try soon

Thanks a lot for the answers, I'll try soon

make sure your CPU frequency scaling governor is in performance modus

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor



and if you are using git mesa
try starting xonotic like this:
> R600_DEBUG="sb" xonotic

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

Does that bring any improvement at all over the ondemand scaling governor?

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

Does that bring any improvement at all over the ondemand scaling governor?

yes, substantially in my case, as does R600_DEBUG="sb" xonotic , it uses a much faster codepath

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

Does that bring any improvement at all over the ondemand scaling governor?

yes, substantially in my case, as does R600_DEBUG="sb" xonotic , it uses a much faster codepath

That's strange. I should try that sometime, but it seems weird to me that it would make such a significant difference.