CPU% for AA

[Joe]

I was just messing around with my activity monitor and noticed why playing AA online that it uses 75-90% of my CPU. I was just wondering if that is extremely high and could be the cause of my craptacular pings in euro servers or if it's just my G4. To get an idea itunes only takes 7.8% and msn is 20%. 75-90% seems rather high for AA, could there be another problem??

[Lucifer]

Unlikely there's a problem, AA takes all available CPU. If it didn't, we'd have 10x as many lag complaints as we have now, and 20x as many fps complaints as we have.

The server can be limited, but afaik, the client can't. If this is a problem, I'd suggest filing a feature request on the tracker.

[Z-Man]

Not completely right. AA takes all the CPU time it needs to simulate and render the scene as fast as you'll allow it to. There are two contitions under which that makes it take almost everything that is available:
- You set your graphics card driver not to wait for VSync. AA will then run at the highest possible framerate and therefore also use all the CPU time available. If you enable the FPS display in the HUD options and it shows more than 100 FPS, then that's your problem.
- When it tells your video card driver to update the screen now, the driver goes into a special CPU-hogging mode until the command is completed, even though all it does is sit around and wait. Both NVidia and ATI drivers are guilty of this. In the "Performance Tweaks" submenu of the graphics settings, there is the "Flush" menu item where you can tweak AA to not issue the problematic command (with possible side effects).

It's highly unlikely that high CPU usage would cause lag. The network stack of your operating system should be running at a higher priority than all applications, so we can't possibly block it.

[philippeqc]

Added z-man's answer to the FAQ in the wiki.

[HEXadecimal]

what are you doing playing on a mac in the first place?


just kidding

[Jonathan]

They work fine for a game like Armagetron with fairly low and consistent load. And compared to typical 'PCs' that aren't specifically built for games they're not bad at all. As posted elsewhere I'm not sure how the software compares in terms of gaming.

P.S. 27 days after the last post?

[Joe]

He's a WIeNNER

[Phytotron]

I remembered Invader talking about this with his Mac. I never played in windowed mode (which would be required for me to watch the Activity Monitor, right), so I never checked it out. Now my computer is good enough to do so, so I did. Yep, high 90% CPU usage. So, I looked up this topic. I also read here: http://forums3.armagetronad.net/viewtop ... =CPU+usage, which delved more into the subject. As I recently mentioned in another thread, I too now get some high FPS numbers (3-400, at least at the start of the round).

So, I downloaded the ATI Displays app. [By the way, now only available on AMD's website, apparently. MacUpdate and VersionTracker, to name a couple, don't have it. So the link provided by nemo in that other thread is invalid anymore.] I also switched around between the different swap modes, and in all combinations with VSync on or off. Had strange results, or at least ones that don't jibe with what Z-man describes should occur, if I'm understanding it correctly.

• Turning on Vertical Sync had no effect on FPS when in windowed mode. It only capped off when in fullscreen. Swap mode didn't seem to matter much once VSync was on; each started at about 85fps, and seemed would average about the same through the round, all else being equal. (When VSync was off, "Finish" did reduce overall FPS, as expected.)

• "Finish" was actually the only swap mode that showed a reduction in CPU usage, to about 70% at peak in a simple local game. Although, once in a server with a lot of shit going on, right back up to 90+%. In other words, no real reduction in CPU usage, at least in windowed mode. *

• ATI Displays is supposed to only affect the selected app, but it affected both versions of AA I used. This may be more its problem.

I guess that's it.

* Might it be possible that, in the same way that FPS was only affected in fullscreen mode, that CPU usage might be the same? Obviously, I can't view the activity monitor while in fullscreen, and I don't know of a way (haven't looked up a way) to make any sort of record. For the meantime, I've left it in "finish" with VSync on. What do you think? Not that I plan to get back into playing much; just curious about all this.

I used both 0.2.8.2.1 as well as the 0.2.8.3_rc2. Again, eMac g4 1.42, 1GB RAM, ATI Radeon 9600.

(By the way, is rc2 what you meant by "latest snapshot?" If not, does that mean rc2 recordings are worthless to you these days as well? If so, would you point me to the place to pickup the latest snapshot; I can't follow that stuff anymore.)

Incidentally, windowed mode is really jerky, too, and not in a low-FPS kind of way. Just jerky, like other another app is running a process.

[Z-Man]

* Might it be possible that, in the same way that FPS was only affected in fullscreen mode, that CPU usage might be the same? Obviously, I can't view the activity monitor while in fullscreen, and I don't know of a way (haven't looked up a way) to make any sort of record. For the meantime, I've left it in "finish" with VSync on. What do you think?

If it works for you, then fine. The reason there are different swap modes is that each driver implements them differently. The theoretical best experience (no tearing, least input lag) for high end machines is given by VSync on, swap mode on flush, and the way the code is organized is optimized to that. BUT: in some cases, and your Mac seems to be one of them, doing so causes poor parallelism between GPU and CPU. The CPU does its thing, tells the GPU what to do, and then waits for the GPU to finish. The 'flush' setting can prevent that, it eliminates the waiting (giving more performance and sometimes less CPU load, depending on how the wait is implemented, which depends on the driver), so while the GPU is rendering the last frame, the CPU can already prepare the next. So you get better throughput by that, but the price is a completely unspecified amount of latency, because there's no limit on how many frames can be buffered in the GPU instructions.

And yep, your driver seems to ignore VSync setting in Windowed mode. Nothing much we can do there.

And rc2 is fine for debug recordings. But don't expect them to be too useful for troubleshooting rendering issues. All we can see from them is how much time your machine took to send the render instructions of each and every frame to the GPU.

[Jonathan]

One problem with vsync combined with lack of finish is that it essentially turns the very end of the pipeline into a bottleneck. The result is a few frames being buffered everywhere I tried, no matter how stupid that seems. Thoughts: APPLE_fence/NV_fence (on my Mac only the Apple version is supported; how's support elsewhere?)

[Z-Man]

That sounds like a good idea; the NV extension is supported even by the legacy NVidia driver on Linux, and of course the current Windows driver. Where it's not supported, we could switch the current loop of

update
draw
swap
finish
clear

to

update
finish
clear
draw
swap
flush

That would at least make the update code run in parallel with the GPU and won't produce more than one frame of latency. Flush was found to be basically free, yes? Then we could add another one right after the clear to give the GPU something to do while the draw code is preparing stuff.

[Phytotron]

Alright. Like I said, just curious about the basic workings and apparent discrepancies between my experience and what you had previously described.

And, no, I wasn't planning on doing any recording about this or anything else to do with rendering issues (that I'm aware).