Jump to content
  • Advertisement
Sign in to follow this  
toddel

Multicore Programming and the future

This topic is 4838 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Just thought i'd see what other think of how next gen engines are going to work with multicore chips and middleware physics SDKs. I've been think about this alot lately and i'm imagining that the physics simulation (Havok, Novodex) could possibly be running in a seperate hardware thread than your game logic thread. It seems this could lead to huge problems with synchronizing the game logic world as the two pieces seem tightly coupled. As game logic needs to make decisions based on collision, body moventment, etc, and physics needs to know if new forces have been applied to these bodies. Thougts??

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!