There are certain effects that appear at certain locations in the game doom3 that reduce framerate by about half. One is the first room in Mars City Level 2 where there are a number of terminals and red fog alcoves build into a wall opposite the lift (see attached image). System: 3.8 GHz PhenomII x4 core AMD processsor 4GB DDR3 RAM Sapphire Radeon 6950 graphics card $yum info xorg-x11-drv-ati.x86_64 gives: Installed Packages Name : xorg-x11-drv-ati Arch : x86_64 Version : 6.14.3 Release : 3.20111125git534fb6e41.fc16 Size : 1.2 M Repo : installed From repo : updates Summary : Xorg X11 ati video driver URL : http://www.x.org License : MIT Description : X.Org X11 ati video driver.
Created attachment 57675 [details] Doom3 image of affected area.png
Created attachment 57676 [details] glxinfo
Created attachment 57677 [details] Doom3 log
Created attachment 57678 [details] Xorg.0.log
I suspect what happens is that in those cases it just can't sustain the monitor framerate, which by default (to avoid tearing) currently results in half that framerate. Some possible ways you could get an improvement: * Does page flipping work any better? Why did you disable it? * Try a recent Mesa snapshot, and possibly also xf86-video-ati and kernel snapshots which allow enabling 2D color tiling. That might just give enough of a performance boost to sustain the monitor framerate in all cases. * If you don't care about tearing avoidance, disable it with Option "SwapbuffersWait" "off", and possibly also run Doom3 with vblank_mode=0.
"Does page flipping work any better? Why did you disable it?" Sorry, I thought I had set it back to the default for EXA. However I've now stopped setting it after trying it with and without, neither made a difference to observed effect. "Try a recent Mesa snapshot, and possibly also xf86-video-ati and kernel snapshots which allow enabling 2D color tiling." I thought I'd enabled colour tiling. Could you give me an idea what would be a recent enough Kernel and Mesa? "If you don't care about tearing avoidance, disable it with Option "SwapbuffersWait" "off", and possibly also run Doom3 with vblank_mode=0." I've tested it with this and I get much higher framerates but I still get the 30 FPS or so hit in the same place. Now instead of normal game rate of 70-80 FPS I get 40-50 FPS in that area. "I suspect what happens is that in those cases it just can't sustain the monitor framerate, which by default (to avoid tearing) currently results in half that framerate." I don't think that is what's happening, because the change in frame rate is normally quite distinctive in cases where that is happening. On my 60Hz monitor it normally jumps between 60 FPS and 30 FPS, but the framerate in doom3 is all over the place. I've had the same effect with settings I've been unable to reproduce of 10-20 FPS in that spot, and as mentioned above with framerates of 40-50 FPS in that spot. Also I've made sure that vsunc is turned off in the game for all my testing.
> I don't think that is what's happening, because the change in frame > rate is normally quite distinctive in cases where that is happening. On my 60Hz > monitor it normally jumps between 60 FPS and 30 FPS, but the framerate in doom3 > is all over the place. I've had the same effect with settings I've been unable > to reproduce of 10-20 FPS in that spot, and as mentioned above with framerates > of 40-50 FPS in that spot. Also I've made sure that vsunc is turned off in the > game for all my testing. Turning off vsync in game didn't work in a test I just did with vblank_mode=2 - but I can't remember what the default is - you should be able to see if you are tearing or not. I only have the demo and different hardware to you (4890), but the fps counter on doom 3 has always been all over the place for me with vsync disabled. I think it's just the way the counter + game works. The game by default will cap at around 60fps and like etqw I suspect if it knows it can't render a frame in the next refresh it won't try whether vsync is enabled or not. You can turn this off in console with com_fixedTic=-1
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
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.