Whenever some new geometry appears (even for weapon projectiles), the framerate drops drastically for a short time. This is a frequent event, so the game becomes unplayable overall. There is also a big preformance drop with the old compiler, when several players get gibbed at once (happens frequently on as-convoy), but with the llvm compiler this is much worse. I'm not an expert on this, but it seems as if a new vertex shader would be compiled for each vertex array submitted, and the llvm compiler is an order of magnitude slower.
FWIW, I suspect it's more likely (re)compiling fragment shaders than vertex shaders. Possibly related to constantly changing fixed-function emulation shaders, UT2004 seems to burn through those quickly (this also caused slowdowns with fglrx's shader cache when the game was new). Just an idea, maybe this is different.
It might not help in fixing this, but I found that the framerate is much more consistent if I load all cpu cores with something while playing ut2004. Normally, the framerate counter is green, but flashes into yellow and purple, which makes movements very choppy. When something is running in the background, the framerate counter stays green, and all movements are smooth. With the llvm compiler the game is unplayable either way.
(In reply to comment #2) > It might not help in fixing this, but I found that the framerate is much more > consistent if I load all cpu cores with something while playing ut2004. > Normally, the framerate counter is green, but flashes into yellow and purple, > which makes movements very choppy. When something is running in the background, > the framerate counter stays green, and all movements are smooth. Maybe cpufreq is causing this here's what I get on the demo on an HD4890 + 4x3.4GHz phenom II. R600_LLVM=0 ut2004 as-convoy?spectatoronly=1?numbots=8?quickstart=1?attractcam=1 -benchmark -seconds=120 -nosound cpufreq ondemand - 30.027578 / 76.497787 / 162.457611 fps cpufreq set to performance 37.627441 / 93.523949 / 197.051376 fps > > With the llvm compiler the game is unplayable either way. I see the stalling in the demo benchmark. 2.030273 / 70.589706 / 196.047073 fps
This is not related to cpufreq. I've fixed my governor to the highest frequency and still experience these massive lags.
(In reply to comment #4) > This is not related to cpufreq. I've fixed my governor to the highest > frequency and still experience these massive lags. Since I cerated a startup script for ut2004 that does 'set all cores to performance ; ut2004 ; set all cores to ondemand' the game runs smoothly without any lag.
Now I took a new look at the issue with GALLIUM_HUD=fps, and there is definitely a serious problem with cpufreq. I have a few scripts to switch cpufreq governor between performance and ondemand (Phenom II x4), and to switch between high and low gpu power profiles (HD6850). When ondemand is selected, it seriously limits performance, and causes noticeable variance in fps. Some examples: Psychonauts, main menu (Raz standing on top of the giant brain) ondemand/low 20 fps ondemand/high 40-50 fps performance/low 29 fps performance/high 104 fps SW:KoToR, the main character standing alone on Dantuine, looking at the Ebon Hawk ondemand/low 20-30 fps ondemand/high 20-30 fps performance/low 55-60 fps performance/high 68 fps The difference between ondemand and performance makes a huge difference in native games as well. Quake Wars, Team Fortress 2, and UT2004 are all borderline playable with ondemand, but run perfectly with performance. It's not just a drop in fps, but a very noticeable laggyness, that kills the games.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/413.
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.