Sign in to follow this  
Roots

How freely do you use multithreading in your games?

Recommended Posts

I'm a little curious how much or how little people here typically use threads when making their games. I think almost everyone puts their audio code in seperate threads (correct me if I'm wrong), but what about other pieces of game logic? I was thinking this morning about what happens when a new map loads in my game, and the answer is a lot. There are several calls to memory, some objects are constructed dynamically, etc. and if I tried to do all that computation inbetween two frames, there's an obvious lag in between. So to 'hide' that slow down, there are obvious tricks like fading out/in the old and new frames, and I thought maybe it would be a good idea to offload that computational work to a thread or something during that phase. I've done my fair share of multithreaded programming before, but never in a game. So I'm just curious to hear everyone's experiences with threads and game programming. [smile]

Share this post


Link to post
Share on other sites
I know next to nothing about threads [except how difficult the bugs they tend to produce!]. I've only tried once, with your aforementioned audio thread. It actually worked kinda well.

Still, my [exceptionally limited] experiences are that if something can be done without threading, it's usually better not to use them. They're on my list of stuff to learn better, but not at any priority.

Share this post


Link to post
Share on other sites
If you can set the data structures (and allocators) up right, offloading resource-loading code is great, especially for streaming.

For my next project (which will have streaming), I'm thinking of doing one for audio, a few for physics (since NovodeX runs in seperate threads, IIRC), one to manage resource streaming, and then the main one which ties everything together and sends polys to the GPU. The GPU kind of counts as a seperate processor/thread, but not in the conventional sense :).

I've only done a bit of threaded code, so I'm sure the race conditions are going to be fun.

Share this post


Link to post
Share on other sites
If you run similar tasks in diffrent threads, there are no performance benefit, unless you have multiprocessor or multi-core system. I would only prefer to seperate such things like networking or IO into different threads, because they generates small cpu overhead, but takes a lot of time.

Share this post


Link to post
Share on other sites
I use one thread for the physics and one for the graphics in my engine at http://www.coolgroups.com/amaze/amazesetup5.exe.

Mike C.
http://www.coolgroups.com/

Share this post


Link to post
Share on other sites
all multithreading i have made was in networking and yet it produces lots and lots of problems. for example a message to delete a certain object from the client database. You cannopt dleete it directly because the client might be in the process of using the same object thus making the game crash. so you have to set a certain object state to deletion so the client will check the flag , iuf it is true it will delete the sepecifed object.
This is a small example of how multithreading can complicate life.
yet it has several usage and without it i couldn't have completed my game .

Share this post


Link to post
Share on other sites
I started a game and used multithreading for the first time.
I made two threads:
1) all the windows stuff like: msg processing, drawing a buffer to the screen with some refresh rate, and because that is the main thread he also creates the second thread.
2) All the game logics, maths, input from user. the advantage in this is that I can write a continues code while the first thread must be a loop.

Because I don't use sound yet I didn't make a 3rd thread yet but i think that audio, windows messages and outputs, game logics and input, networking, and each subsystem inside the game that shouldn't depend on the others, should be seperated into diferrent threads.

Share this post


Link to post
Share on other sites
I have quite a few friends with dual-processor Macs, so I have leaned pretty heavily toward multi-threading in my projects.
As an example my current project is an infinite-LOD planet renderer, and the tiles are loaded on the fly by a separate thread.
I would probably use even more threads, but I use SDL, which requires all input and video calls be made from the same thread, and also I haven't come up with a decent approach to make threads play nicely with my kernel/task system.

Share this post


Link to post
Share on other sites
I use them when I must, or when the benefits are large enough.
For example, to enable non-blocking handling of blocking IO-calls or to feed polled status data into a message/event queue.

The basic rule is to never use threads unless you have to. The problems of proper synchronization, exception handling and sequencing often outweighs the benefits of multiple threads. Heavy thread synchronization also have a tendency to reduce performance compared to a non-threaded solution.

Share this post


Link to post
Share on other sites
I never use them unless there's no other effective way to do it. My most recent game is multiplayer, and has a couple threads to sit on (blocking) network sockets and read from them into a queue. That queue is the only way the thread touches any other part of the program.

Share this post


Link to post
Share on other sites
I put my message pump and my game code in separate threads, just so I can forever split off the stupid windows stuff (boring) from the interesting game stuff (fun!). I would otherwise not use it, unless I was doing something like multiplayer support, in which case it would be a good idea to do the communication stuff in another thread...

I'm sure threading can help design a really nice architecture, but the fact that thread-based things are a pain in the ass to debug (since bugs having to do with thread interaction are hard to trace due to randomness of how threads are switched between) outweighs the benefits IMHO.

Share this post


Link to post
Share on other sites
I haven't used many threads for things I've done as they've all just been simple things that didn't gain anything from over doing it with threads, but the main thing about them is take your time with designs so you know what they're doing.

Aslong as you're careful and know what you're doing, threads are great, as long as they're clean. If you get lazy in any part of them, and start making 'shortcuts' then you're screwed, and might have to start over rather than figure out where the hell that random bug that pops up 1 in 50 times.

Share this post


Link to post
Share on other sites
Well... I usually don't use multithreading very much tbh! In general, I'd also say don't use it unless there's some benefit to it, because multithreaded issues are hard to debug.

The main places I've personally seen where it's useful are:

1. Things that will stall the machine...
A) Networking code in some cases
B) Loading large maps

2. Multiprocessor / hyperthreading

3. Some background task that needs to continue running (e.g. sound)

roos

Share this post


Link to post
Share on other sites
1+ thread for sound engine.
1 high priority thread for timmer.
1-2 worker threads for 3D engine. There might be additional helper threads.
1 - multiple for game engine.
5+ worker threads for game engine.
If world engine is separated then some threads of game engine are in fact threads of world engine.
possibly passive input thread, if polling of input devices isn't fast enough, or don't work well on high priority, to be done in some executions of the timmer thread.

All of them are async as much as possible, or more. There is some methodology for multithreaded FAST 3D engine, and I developed error cancelation that seems to work to some extent with world engine.
There might be also low priority prefetch threads, and critical safe shut down thread sleeping until needed.
And yes I often don't use thread for inicialization for actual running the game. Just if something would go wrong it's a nice safety net.

If sleeping would work better under windoze XP, you could play a game, and do rendering on background at the same time. Of course such things work better under Linux.

Share this post


Link to post
Share on other sites
I tend to use threads all over the place.
The networking engine I use is highly threaded to the point all processing is detached to a thread.

Graphics I tend to keep in one thread.

Windowing and messaging go in same thread as graphics because I really don't care about it that much.

games generally aren't thread heavy due to the complications with them, static buffers are a real problem in threads. So most people stay away. There are locking routins to ensure thread sychronization, but then that sort of ruins the point of threading your application.

If you're finding out you have to mutex every thing then you probably shouldn't be using them.
Another thing is a lot of libraries (OpenGL) aren't very thread safe. If you read about threading in OpenGL its threadsafe as long as you lock all calls to it. Which basically tells me its not rentrant.

Share this post


Link to post
Share on other sites
More threads are good.
More sync needed (ie. Mutex, Semaphores, Condition Var) is bad.

In gaming there are thousands of good places to open up your logic into new threads.

A good example would be Unreal Tournament 2k3, the newest one...
It has a seperate thread for each piece of its gameLogic.

http://cache-www.intel.com/cd/00/00/20/40/204080_204080.pdf

That is a rather interesting article for anyone who wants to further the proof.

Share this post


Link to post
Share on other sites
Quote:
Original post by anonuser
Another thing is a lot of libraries (OpenGL) aren't very thread safe. If you read about threading in OpenGL its threadsafe as long as you lock all calls to it. Which basically tells me its not rentrant.


which makes sense, as your gfx card cant multi-task, which means some locking is going on 'somewhere' in a reentrant API like D3D.

My point of view as to why a re-entrant gfx API is not really usefull can be found here.

edit:

and for the record, I'm kinda in the process of testing a system which handles rendering via interpolation in one thread, world updates in a 2nd and leaves window and message handling to the main thread. The rendering is done via OpenGL.

I'll probably also require a thread for sound at some point and networking will be handled by whatever networking library I decide to go with so I wont have control over threading there I dare say.

Share this post


Link to post
Share on other sites
Once I personally have a dual CPU, I might be willing to go through sync debugging hell for the extra performance, but until then it's not worth the added development time for a hobbyist programmer like myself.

Share this post


Link to post
Share on other sites
In non game-like applications i use threading a lot, but in games, i never needed to use one...(I Dont count Audio/Physics libs who handle threads themselves not requiring extra control over them)

Share this post


Link to post
Share on other sites
Quote:
Original post by Raghar
1+ thread for sound engine.
1 high priority thread for timmer.
1-2 worker threads for 3D engine. There might be additional helper threads.
1 - multiple for game engine.
5+ worker threads for game engine.


Please tell me you're joking? Am I the only one that thinks this is extreme overkill? I have no doubt you are losing alot of performance in thread management alone.

Share this post


Link to post
Share on other sites
Quote:
Original post by DrEvil
Quote:
Original post by Raghar
1+ thread for sound engine.
1 high priority thread for timmer.
1-2 worker threads for 3D engine. There might be additional helper threads.
1 - multiple for game engine.
5+ worker threads for game engine.


Please tell me you're joking? Am I the only one that thinks this is extreme overkill? I have no doubt you are losing alot of performance in thread management alone.


I don't think it's necessarily overkill - chances are that the threads for the most part are yielding and waiting for an event to perform a specific function (i.e. an event triggers a need to load a new resource from disk -> boom -> use one of the worker threads)...

The main performance hit comes from the thread initialization and startup - once it's running, you can just let it idle until it needs to act... now, writing the code to manage that and to make sure things are synched when they need to be, that would be a bit more of the challenge for me...

just my 2c.

Share this post


Link to post
Share on other sites
What would 5+ worker threads be blocked on in a game engine? And 1-2 threads for the 3d engine?

I fully understand threading networking, sound, and file IO to support asynchronous asset loading or something. Beyond that I have a hard time seeing where else additional threads would benefit in a game.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this