Since I recently had to delve back into threading for my game, I was curious as to what areas you use threading for?
I already know the most important parts I have to convert to threads in my game, this is just to see if maybe there might be other relevant areas I may have not thought of...
What do you thread?
All file operations - so I can use the main thread to render an animated loading screen, or stream in the next level whilst playing the current one.
Multiprocessing requires additional design and introduces complexity that is generally avoided in games.
Many times you can use threading with no significant work. Most I/O calls offer asynchronous versions. (I/O includes everything from graphics to audio to file system access.) This type of threading requires very little work on your end if you can do other things while waiting for it to complete. You will need to either query or handle a callback, but that is minimal effort for the huge benefit.
There are some fire-and-forget tasks you can do in C++, such as freeing up resources and assorted garbage collection. Other languages take care of this as a background task, and it is something you don't normally need to block on before it completes.
You can often break out time consuming tasks into their own threads, as was pointed out earlier. It requires some design work to make sure you don't corrupt your data, deadlock, or cause other problems. These can generally be placed in a lockless queue by the main game threads, processed and removed by a worker, and then added to a "done" queue when processing is complete. These tasks can include pathfinding, physics processing, and other tasks.
Those are the most common forms that you will encounter.
More complex forms require significantly more work.
Sometimes you can get great benefits from parallel processing algorithms; searching is the best example as it can give superscalar results. Master/Slave processing for trivially parallalizable functions and thread pools can work for you if you have a bunch of tasks with unknown duration and want to load balance on multi-core machines. Sometimes you can use it for parallel effects processing.
But they require more work to keep the processing thread safe to prevent data corruption, race conditions, and deadlocks, and other problems.
Finally, there are whole classes of parallel processing algorithms, as opposed to serial processing algorithms that are most often used. Generally they don't apply to interactive game processing today, instead focused on offline processing of large data sets. They are typically covered in the last years of undergraduate school and more in depth during graduate school. You generally won't see this type of thing in mainstream games, but expect it to change in the future.
Many times you can use threading with no significant work. Most I/O calls offer asynchronous versions. (I/O includes everything from graphics to audio to file system access.) This type of threading requires very little work on your end if you can do other things while waiting for it to complete. You will need to either query or handle a callback, but that is minimal effort for the huge benefit.
There are some fire-and-forget tasks you can do in C++, such as freeing up resources and assorted garbage collection. Other languages take care of this as a background task, and it is something you don't normally need to block on before it completes.
You can often break out time consuming tasks into their own threads, as was pointed out earlier. It requires some design work to make sure you don't corrupt your data, deadlock, or cause other problems. These can generally be placed in a lockless queue by the main game threads, processed and removed by a worker, and then added to a "done" queue when processing is complete. These tasks can include pathfinding, physics processing, and other tasks.
Those are the most common forms that you will encounter.
More complex forms require significantly more work.
Sometimes you can get great benefits from parallel processing algorithms; searching is the best example as it can give superscalar results. Master/Slave processing for trivially parallalizable functions and thread pools can work for you if you have a bunch of tasks with unknown duration and want to load balance on multi-core machines. Sometimes you can use it for parallel effects processing.
But they require more work to keep the processing thread safe to prevent data corruption, race conditions, and deadlocks, and other problems.
Finally, there are whole classes of parallel processing algorithms, as opposed to serial processing algorithms that are most often used. Generally they don't apply to interactive game processing today, instead focused on offline processing of large data sets. They are typically covered in the last years of undergraduate school and more in depth during graduate school. You generally won't see this type of thing in mainstream games, but expect it to change in the future.
Animation, AI, view culling, displaylist preparations, particles, physics, file IO (and decompression), sound. There are tonnes of things in a game, that with proper design are quite parallel.
And I don't mean putting Animation in its own thread. Instead I mean breaking up animation by skeleton and droping all the animations into a thread pool to split the work up. Same with almost everything in my list. Games have tonnes of objects running around, and updating them all in parallel at different stages of the engine gives you some large gains.
And I don't mean putting Animation in its own thread. Instead I mean breaking up animation by skeleton and droping all the animations into a thread pool to split the work up. Same with almost everything in my list. Games have tonnes of objects running around, and updating them all in parallel at different stages of the engine gives you some large gains.
Besides splitting certain things into their own threads, if you are using C++, Intels Threading Building Blocks will help you to process things in parallel like frob is suggesting.
In short my plan is to do 'everything'.
Although to say I'm using threads would be slightly wrong as I'll be using tasks with the aforementioned Threading Building Blocks library so I constantly have N threads spinning over M tasks.
As I'll be targetting DX11 only threading becomes a 'no brainer' with graphics and I've spent some time of late figuring out how integrate IOCP with a task based system so that loading of data can be fired off and picked up X frames later when ready.
In short; forget about threads.
Thinking in tasks is the way forward [grin]
Although to say I'm using threads would be slightly wrong as I'll be using tasks with the aforementioned Threading Building Blocks library so I constantly have N threads spinning over M tasks.
As I'll be targetting DX11 only threading becomes a 'no brainer' with graphics and I've spent some time of late figuring out how integrate IOCP with a task based system so that loading of data can be fired off and picked up X frames later when ready.
In short; forget about threads.
Thinking in tasks is the way forward [grin]
Quote:Original post by phantom
In short my plan is to do 'everything'.
[...]
In short; forget about threads.
Thinking in tasks is the way forward [grin]
+1.
Quote:Original post by phantom
In short; forget about threads.
Thinking in tasks is the way forward [grin]
Completely agree.
Author
I have been considering using OpenMP for doing the thread work. As far as the difference between tasks and threads, I'm not getting your meaning. To me threads=tasks since I threaded the entire function, in this case my entire Ogg audio sub-system.
As for file I/O, in some cases I could do that but since it is a portal based system, I can't preload the next system until the player chooses to go there.
As for file I/O, in some cases I could do that but since it is a portal based system, I can't preload the next system until the player chooses to go there.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
