Multicore Programming and the future

I thought that the physics would work pretty linear - ie the update is called from the game loop, and the actual processing of physics objects would be multithreaded - ie, having two/three/four seperate threads to process objects. Its quite difficult to imagine how its going to work if you've not done any parallel programming before, hence how I find it so difficult to imagine aswell.

The current engine i'm working in is heavily multithreaded. One thread each for Graphics, UI, Dataloading, and Game logic/physics. We are verymuch toying with the idea of using a 3rd party physics SDK next. With the upcoming multicore system as well the physics accelerator chips from Agei, im just wondering how to paralellize the two components as the seem very much coupled. I guess one possible solution could see the game logic interpolate/predicate until it receives a new update from the physics simulator. I know some engines do this on the render side of things when the world hasnt updated between graphcis frames...

I've thought about doing that before - rendering predicts, and the physics just passes out real values every once in a while (well, 10ms) would be easier to implement networking that way. After writing code single threaded for, well, all my programming life, I want to jump into multithreaded programming. I got the hang of OO pretty quickly, I think multithreaded programming is gonna be the same sorta thing - difficult to grasp for some people, then you get people who just have it straight away. Its thinking of ways to split up code and have it cooperate thats bugs me.

Physics and rendering are decoupled processes. Ie there is no necessity that what is displayed is synchronous to the motion in time and space. The render is only sampling the present state. Motion is an illusion. An object doesn't necessarily need to know that it is a discrete phenomenon. As far as it cares, it queries it's environment, and it can do nothing futher until a response is delivered. Classic, a FSM. extend it to be parallel and message based.

They are discrete processes not continous. It's an illusion ;-) Physics is usually in the server kernel anyways. Client is just another object in the kernel. For a client, it must at least be satisfactory to the player that the illusion is continuous.

From a rendering standpoint that makes complete sense, but what about from the game logic standpoint? If the next generation of games are to be using advanced physics middle to make interaction of the environment all the more immersive it seems the game logic and physical simulation are tightly coupled. In most game engine designs that i know of, they are run in the same thread so communicating/syncing between the two is not an issue, they run lock step. In an engine that has 2 seperate threads (1 game logic, 1 physics). It seems there would need to be much communication between them. Either sampling at a certain point or message passing when events such as collisions occur.

The easiest way we've found to take advantage of multi-core is to separate rendering from everything else (UI + game logic + physics). Rendering being a readonly thread means the simulation thread does not need to lock data for reading. We use only about half a dozen critical sections to achieve 80% utilization of the second processor.

We are currently looking for engine programmers.

In my engine, modest though it is, rendering, game logic and physics each have a separate state. They are updated independantly in different threads, but can modify and query each other to an extent. For example, whenever the game logic decides an object should be moved, it also sets the corresponding render objects location. But the mutex is per object, so you can move all the objects in the level 1 meter in a single frame for the game logic, and find a frame was rendered in which only half of the objects had been moved. Although I have very little physics, it works similarly. But because I like the game logic to be boss, it just queries and modifies the state of the physics simulation when it feels the need to.

Basicly, all this means that there need not be any synchronisation between the threads. You could fail to update the game logic, it'd still render. You could fail to render (i.e. minimised) the game continues. You could bog the physics down, and keep a passable framerate.

Quote:

Original post by Name_Unknown Most game engines use a client-server model, which is already a form of parallelism of it's own. Quake,Unreal, etc all have physics on the server side as far as I know, the client is just a a dumb super-computer with a fast graphics card. The client carries out calculations but the server is the authority about the world. Generally, clients have a very trivial simple collision test. When they are wandering aimlessly without feedback from the server, it is there so they don't walk through walls. In Quake there was a rare bug when sometimes you could get stuck inside other players because it was not sync'd exactly with the server, and would 'pop' back inside someone else. It was really annoying too. You can shoot but unless the server authenticates, it's just eye candy. AI is almost always in the server kernel, it is quite close to the physics kernel, so it doesn't experience a delay like a client over the network would. Single player games have bother server and client on same host. Right there you have exploited half the problem of parallelism ;-) I'm not saying it's trivial, what I am inferring at is that you need to change the way your perceive the problem and how you design it.

Most FPS and action games do this, i should've been a bit more specific in the engines i'm talking about. I work with RTS and traditionally they are lock step with one another, all computers simulate the world due to the overhead you would incur sending messages about hundreds our thousands of objects across the wire. i think thats another discussion in itself (differen net models for RTS). even in the client server model of FPS i still see it being a problem have game logic and physics threads being on seperate cores. RAZORUNREALS solution was something along the lines of what im thinking send messages to each of the threads when object state changes..

It may be interesting to examine the model used by modern graphics cards.

An API layer simply submits commands to the graphics card, and the graphics card will queue and flush the commands as appropriate.

This makes it difficult to extract data from the graphics card. But there is the concept of v-sync... basically a guaranteed update interval. If a frame takes longer than the v-sync period, the update interval is then decreased by 0.5 (i.e., a game running with a v-sync of 60hz will top out at 60 fps, if it drops below 60 fps it will "snap" to 30 fps).

You can also issue queries to modern graphics cards. The results are not often returned immediately, requiring frequent polling to see if the data is ready yet. It is possible to spin while waiting for results, but this also stalls the rendering pipeline. People have done some work on interleaving queries to make sure the results are "guaranteed".

I wonder if a similar concept (vsync and/or queries) may work for a physics chip as well.

well it would use 2x the memory but

struct State {
info pos_and_stuff;
bool is_being_modified;
};

State old, new;

ThreadSafeGetPosAndStuff()
{
if ( new.is_being_modified )
return old.pos_and_stuff;
else
return new.pos_and_stuff;
};

assuming the delta time is reasonable no one will notice your dude hasnt moved yet. but i have no experience threading so......