CPU intensive game - need dual core support?

[Cycrow]

well, actaully in a standard game engine, there all done in sequence

each cycle, the engine first computes the AI to controll al lthe AI controlled objects, then it applies the physics calculations on it, then after that it finally renders onto screen

its possible to make it multithreaded, but it neds to be designed that way in the first place, changing after the game engine is done is quite a challenge

[Sureshot_77]

I was mucking around with X3, with the task manager running on my second monitor (After all I have to use it for something since Egosoft dropped multi-monitor support...) and was suprised to see my CPU usage break 65%.

Now on a single CPU system, that wouldn't be all that interesting, but it showed on my Athlon 3800+ X2 system that it was using the second core, to the tune of 30% of it's total usage.

This was pretty consistant, with usage never dropping below 55%.

Now I have applied the X2 AMD patch, and the Windows XP patch, so my O/S is now spreading the threads across the two cores as i should, but it shows that some part of X3 is running dual-core.

Now we just have to stretch that 30% usage of the second core to 90%.

[aka1nas]

I was mucking around with X3, with the task manager running on my second monitor (After all I have to use it for something since Egosoft dropped multi-monitor support...) and was suprised to see my CPU usage break 65%.

Now on a single CPU system, that wouldn't be all that interesting, but it showed on my Athlon 3800+ X2 system that it was using the second core, to the tune of 30% of it's total usage.

This was pretty consistant, with usage never dropping below 55%.

Now I have applied the X2 AMD patch, and the Windows XP patch, so my O/S is now spreading the threads across the two cores as i should, but it shows that some part of X3 is running dual-core.

Now we just have to stretch that 30% usage of the second core to 90%.

Any other processes running will use the other core. Also, if you are running current drivers on an Nvidia card, they already support dual-core and offload some extra DirectX API processing to the second core.

[Kindred Spirit]

Hopefully SMP/multicore support will be considered when they do X4

SMP forever! Dual-core SMP even

KS

[dunnno]

I read Infinity Wards take on HT and multiple core support (which they added to Call Of Duty 2 after the games release) If I find the article again I'll put a link to it here.

A lot of good that did...

[Klyith]

I was mucking around with X3, with the task manager running on my second monitor (After all I have to use it for something since Egosoft dropped multi-monitor support...) and was suprised to see my CPU usage break 65%.

Now on a single CPU system, that wouldn't be all that interesting, but it showed on my Athlon 3800+ X2 system that it was using the second core, to the tune of 30% of it's total usage.

This was pretty consistant, with usage never dropping below 55%.

Now I have applied the X2 AMD patch, and the Windows XP patch, so my O/S is now spreading the threads across the two cores as i should, but it shows that some part of X3 is running dual-core.

Now we just have to stretch that 30% usage of the second core to 90%.

That's normal for a single-threaded app. What is happening is that the process is "bouncing" back and forth from one cpu to another. You can see that both percentages added together equal about 100% of a single cpu. That will happen on any process that has not had a "processor affinity" set.

X3 would probably be easier to multi-thread than some other games. I think they could put the ecomonic engine and all OOS stuff on one, and the player in sector stuff on the other. But multi-threaded progranning is a bear and still has to be done by hand most of the time. When compilers can automatically create code for SMP is when games will move there.

[Mophus]

With all the AI scripts running in the background, each controlling a different ship / station, X3 looks like a perfect candidate for multithreading (separating physics from graphics can be trickier, but running the AI on separate threads should be simple - at the very least one thread for the current sector and one thread for the rest of the universe, which already uses a separate kind of "simulation").

BTW, running X3 on a dual Opteron, with latest drivers, etc., the second CPU never gets above 10% (and I suspect that's mostly the graphics driver).

I don't think X3 is multithreaded at all. If you see the second core or CPU being used, it's probably just by other applications / drivers that you have running at the same time.

It's also annoying that you can't have X3 running in the background. Since I have two CPUs, one of which X3 doesn't use at all, I'd like to be able to at least brwose the net, etc., while I'm waiting for my ship to arrive at its destination. But as soon as I switch to another application, X3 freezes.

- Mophus

[Carl Sumner]

Technically, X3 is certainly multithreaded. But people mean a lot of different things by "multithreaded" or "multitasking". Microsoft being one of the worst for imprecise terminology!

X3 appears to use three levels of threads: Windows standard threads, Local threading controlled by the script processor, and remote threads used by the video board hardware. And maybe more.

Programmers make some assumptions about what is safe from collisions with other threads, and some of these are not valid when multiple cores (or multiple processor boards) are used. If programs are designed with multiple cores in mind then they should run with or without dual cores. If not then the code that uses the assumptions must be changed to add semaphores or mutex mechanisms.

The problems with the game pausing when switched out are because Microsoft and the Video and Audio board manufacturers did not design for multiple access to the board drivers. They crash if most games are switched out and some other process uses the drivers.

[handy388]

"AGEIA PhysX card "

that card sucks. It's a 299.99 card that SLOWS down your game.

[mrbadger]

you could think of X3 as a state machine. It moves from one state to another, but those states cannot occur in paralell.

Were they to occur in paralell, you could potentially have a condition where you are both dead and alive at the same time according to the different threads. This is a boolean paradox, which is something to be avoided. It would probably crash the game.

Therefore, without ripping the whole thing apart and rebuilding it, multi-threaded support would be impossible.

almost all games are state machines these days, controlled by scripts that send comand to the game engine through a global command stack (well, that's one name for it).
where games support duel cores they have been designed from the first alpha versions to do that. I don't know of any mainstream duel core games.

Some have SLI support, but that just means the single threaded engine send graphics output to the cards, and the graphics cards themselves do the SLI bit.

[Jon Tetrino]

"AGEIA PhysX card "

that card sucks. It's a 299.99 card that SLOWS down your game.

Thats more likely because its a card designed for CAD/CAM and other similar programs...


...then again I could be wrong.

[aka1nas]

"AGEIA PhysX card "

that card sucks. It's a 299.99 card that SLOWS down your game.

Thats more likely because its a card designed for CAD/CAM and other similar programs...


...then again I could be wrong.

No it is a gaming card. There is only one released game(GRAW) that supports it and the support was poorly tacked onto a game that already is using the HAVOK software physics engine for most of the effects. So they chose a very inefficient way to support the hardware. To make it worse, the hardware physics mode vastly increases the number of particles and objects in the game and there is no way to use hardware physics with the normal number of objects or software physics with the regular number of objects. So it is very difficult to actually benchmark performance with or without the hardware.

[Jon Tetrino]

so its a waste of money for everyone.

[Cycrow]

it is right now, but u have to give it time for games to actaully come out that uses it properly.

Thats the problem with new technology, most ppl will only get it once its established, which makes it hard to establish it in the first place as companys arn't going to spend time and money producing a game for it that no one can actaully use.

but then the same thing happened with the original voodoo, most ppl laughed at the idea of having a GPU for games.

it only really took off once voodoo 2 was lauched

[Mophus]

Technically, X3 is certainly multithreaded.

Running different threads at different times doesn't really count.

I think Morrowind launched a new thread each time you loaded a game, so some people swore that, on their system, the game ran more than 32 threads. Well, yes, but not at the same time.

Run X3 on a multi-core system, and you won't see it use more than the equivalent of one core at the same time. The process might jump around a bit, as Windows manages other processes, but you'll never get two CPU-intensive X3 threads running at the same time.

Parallelising everything would be hard, of course, but I'm pretty sure they could offload all the OoS simulation to a secondary thread with very little work. Since the two simulations are already significantly different, I'm pretty sure they already have mechanisms in place to handle the "transfer" of entities between them, which should be SMP-safe.

P.S. - The Ageia card was not designed for CAD. Most professional CAD packages come with their own physics code, tightly integrated into the program. They can't afford to have 3rd party hardware produce slightly different results, screwing up all the simulation. Ageia's card is aimed mainly at games. Personally, I doubt physics cards will go very far. It's more likely that a physics processor will be added to graphics cards (a lot of the data about the 3D scene is shared by the graphics and physics engine, so it makes more sense to keep them close together). I have a feeling AMD and ATi might be working on a hybrid solution, possibly with Havok, and probably designed to run on HTX. We'll see.

- Mophus

[ZaphodBeeblebrox]

As a programmer who has written very large multi-threaded applications, I can assure everybody that apart from some very trivial uses, it is not an easy thing to add to an existing program.

Scripting is very definitely NOT a candidate for this.

I agree with Mophus, to some extent, there are parts of the OOS computations that could be made to run in a separate thread, that doesn't mean it would be easy to do though. Making the operations thread safe and avoiding race conditions would take a great deal of analysis, and might not be worth the effort involved.

It is almost certainly not worth the effort for X3.

[aka1nas]

As a programmer who has written very large multi-threaded applications, I can assure everybody that apart from some very trivial uses, it is not an easy thing to add to an existing program.

Scripting is very definitely NOT a candidate for this.

I agree with Mophus, to some extent, there are parts of the OOS computations that could be made to run in a separate thread, that doesn't mean it would be easy to do though. Making the operations thread safe and avoiding race conditions would take a great deal of analysis, and might not be worth the effort involved.

It is almost certainly not worth the effort for X3.

I'll agree that it is probably not economical for X3 for them to reprogram the engine. However, if you look at the way the game works, there would be very little race conditions if you divide up things at the sector level. Sectors are already self-contained and the only time data is shared is when a ship jumps into sector. OOS Sector Data is already not displayed in real time so no loss there. This is basically just message passing between objects to think about it abstractly. To be honest, it doesn't matter if it takes microseconds or 10 seconds for a ship to appear in another sector after it passes through a jumpgate.

[ZaphodBeeblebrox]

Which sounds ok until the player starts looking at sectors from the Universe Map. I can assure you that trying to update graphics from separate threads can cause a lot of problems.

One method, is to ensure that graphics updates always run in the same thread. Therefore you need some means of signalling, (or other synchronisation methods) for when background threads have completed their calculations and the graphics thread can now use the data to do its updates.

Edit:

Yet more problems arise when the player selects a ship from the sector map and gives it orders that will change its course.

[Zakalwe]

OOS update doesn't need to be at a high frequency, right now it's soemthing like one in 3? seconds. I cannot see a real problem with synchronisation. But then i am not a programmer...

In any case seperating OOS wouldn't help much as most CPU usage is used for IS, whatever other people say. Even i have my >>60fps when seeing only starfield in a not busy sector and i haven't got the high-end CPU. It get's slow when there are objects on the screen (I can blame my TI, other players can't).

[Jon Tetrino]

Ok, I went and toyed around with my friends Core 2 Duo rig (he tends to experiment) and after using a resource managment software, we managed to get X3 running on both cores.

When I find the software I'll post a link.