Under Linux CPU usage is much higher when multithreading is enabled.

Average cpu usage with with mt disabled and enabled (The first three are with vsync off).
fps limiter at 0 : 102 146
fps limiter at 60 : 57 126
fps limiter at 10 : 14 106
vsync on limiter at 0: 60 94

The numbers dont really tell the whole story without seeing min max and avg actual framerate during those runs. Multithreading's purpose in VO seems to be parallelizing physics frame calculations, which would cause momentary dips in singlethreaded mode but not so much in multithreading. Does cpu increase? yes. but that's to offset the framerate dips that would have occured in single thread mode.

edit: Also, some games dont simply split existing work onto threads if available, but instead add extra work that otherwise would get processed much less realistically. Not sure what VO's actually sending off to it's threads since the only mentions i've seen regarding it have to do with phsyics processing and consequential handoff back to the rendering thread.

Ray would have to weigh in on this, but this looks like expected behaviour to me.

In a single threaded renderer, the frame-limiter is going to drastically alter how much can get done within a given loop, including the other functions (like physics) that get run within that loop. Generally speaking, the game is GPU bound, so this is likely to be a common case.

In a multi-threaded renderer, the other functions are allowed to run much more "at-will". For physics, there's still a frame timestep limit, and only so many jobs are put into the respective threads, so it's not completely unbounded. But it will use more CPU to provide a much more accurate physics simulation, at a low graphical framerate, than it would otherwise.

Strictly speaking, higher CPU usage with multi-threading enabled is.. the point.

(It's also worth noting that some OSs can be a little weird about how they tally and display CPU usage, particularly where many threads and cores are concerned. I'm not suggesting that's necessarily the case here, just that it might be worth exploring).

The multithreaded rendering puts the game logic and scene management into one thread (in addition to the physics threads) and the rendering thread which sends the commands to the video driver.

Those seets of numbers are percent cpu usage from what tool? How many cpus/cores do you have?

If the game thread is busy, the render thread may spin-wait if it has nothing else to do, waiting for the game thread to tell it to do something. The render thread also does the X Windows input processing since that has to be done on the same thread as the rendering.

So what you're seeing is probably the render thread continuously checking for X events and commands from the game thread over and over very quickly.

I just noticed this because the CPU fan is constantly running at top speed now. I can keep multithreading disabled, so it's not a huge issue.. it's not like it really made a difference so far. If the game does the same thing on android though it might affect peoples battery life.

The numbers are percentages from top. It's a dualcore.

I found another tool called pidstat, which shows per thread statistics. Results on pastebin cause the forum would screw up the formating:

http://pastebin.com/DviGEWR9

If I read this right and the renderer thread is the one whose percentage goes up when the limiter is disabled, it actually looks like the main thread is busy waiting.

Yeah, probably. The render thread is the main thread and needs to continually check for incoming commands from the game thread and X Windows for input.

It may be possible to try to sleep the main thread for some time unit that is smaller than the max fps value.