toglia
07-02-2010 17:01:14
In my personal learning path on making video-games, my attention was recently drawn to multi-threading and I would like to share some thoughts here.
I think maybe sooner or later anyone who want's to be up to date with the current multi core hardware evolution has to wonder how to utilize all these new cores to improve the general performance of the app. Personally I thought it would be easier but after doing some research I found out its a big and profound world I have been very distant to.
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=52818
This topic was really helpful cause I grasped many different ideas on how multi threading could be done, and it seems that the "one core per system" current is getting out dated as its not scalable. Anyway, the valid movement today tries to divide the program into "jobs" or sometimes called "tasks" that would be processed by a task manager that handles those jobs to the cores in a smart way. TBB seems to be a good choice although another framework called concurrent collections by intel happens to be better (as xavier once said, but I haven't heard anyone using it yet)
I think thats a lot of nice theory, but there doesn't seem to be much work trying to adopt these patterns. So, as an nxogre user I would like to know how is the general feeling of the community about these concepts. I know PhysX is closed so having a common work queue (task manager) for the entire application is impossible for now right? So, are we stuck doing physics in one thread only? Is this Nvidias fault to add more importance to the GPU and not the CPU? I know sinbad has propossed a new threading support that would allow ogre tasks to be merged into an external task manager, so thats one step up.
Another thing, as I was reading the "game coding complete" book the author recommended to communicate between threads with a thread safe message queue. In the physics/render scenario, the physics thread would message the render thread to update the position of x actor... I suppose nxogre works this way right? Sorry for not reading the code... I was so lazy I didn't even know if nxogre was multithreaded at all, recently I found out I was only using 2 cores (out of 4) in all my nxogre apps.
Well, thanks for you attention.
I think maybe sooner or later anyone who want's to be up to date with the current multi core hardware evolution has to wonder how to utilize all these new cores to improve the general performance of the app. Personally I thought it would be easier but after doing some research I found out its a big and profound world I have been very distant to.
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=52818
This topic was really helpful cause I grasped many different ideas on how multi threading could be done, and it seems that the "one core per system" current is getting out dated as its not scalable. Anyway, the valid movement today tries to divide the program into "jobs" or sometimes called "tasks" that would be processed by a task manager that handles those jobs to the cores in a smart way. TBB seems to be a good choice although another framework called concurrent collections by intel happens to be better (as xavier once said, but I haven't heard anyone using it yet)
I think thats a lot of nice theory, but there doesn't seem to be much work trying to adopt these patterns. So, as an nxogre user I would like to know how is the general feeling of the community about these concepts. I know PhysX is closed so having a common work queue (task manager) for the entire application is impossible for now right? So, are we stuck doing physics in one thread only? Is this Nvidias fault to add more importance to the GPU and not the CPU? I know sinbad has propossed a new threading support that would allow ogre tasks to be merged into an external task manager, so thats one step up.
Another thing, as I was reading the "game coding complete" book the author recommended to communicate between threads with a thread safe message queue. In the physics/render scenario, the physics thread would message the render thread to update the position of x actor... I suppose nxogre works this way right? Sorry for not reading the code... I was so lazy I didn't even know if nxogre was multithreaded at all, recently I found out I was only using 2 cores (out of 4) in all my nxogre apps.
Well, thanks for you attention.