multithreading in nxogre + personal thoughts

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.

betajaen

07-02-2010 19:36:42

I'd be lying if I said I know about multi-threading, but I don't. The closest I gotten to threads is using Java for college, even then I didn't like it. I'm an old fashioned programmer, and one thread is enough for me.

But I do know, that PhysX has a really good threading interface, which you can place scenes and compartments into different threads, which those can be put on different cores I suppose. The NxOgre Timelistener class can be threaded if needed for tasked updates for scene updating and rendering, well I assume it can.

If you want to split up NxOgre/PhysX into "tasks", then go for it. I know PhysX can support it, and if you want to change NxOgre to be more threaded, or wrap the threading functions/classes in PhysX I'd be happily to accept any patches.

toglia

07-02-2010 20:39:34

Well its somewhat flaterring to hear that cause I am in a very very early process of understanting things. I am not nearly as experienced as many users out there, I only have like 2 years doing "games", but I am very passionate and I hope someday I will be capable of doing a decent scalable game engine based on ogre and nxogre/physx.

I still have a lot to learn about multithreading in general. It sometimes scares me! There so much going on right now that It seems pretty difficult keeping the pace.

deshan

08-02-2010 04:28:06

Last year when i was i uni one of my friend have done a project using nvidia gpu clusters. Their he has told me about PHYSX. thas was the first time i have heard about PHYSX and also it was my first step to nxogre. As he told me GPGPU clusters(multithreaded) are not only used for graphics rendering but also physics calculation. More about CUDA
http://en.wikipedia.org/wiki/CUDA
In the computer gaming industry, in addition to graphics rendering, graphics cards are used in game physics calculations (physical effects like debris, smoke, fire, fluids); examples include PhysX and Bullet.
Is this the reason it require to bundle PHYSX system software along with the project?

edit: http://en.wikipedia.org/wiki/PhysX#GPU

toglia

08-02-2010 15:48:11

Funny thing is I once bought the Ageia dedicated PPU card and I never noticed any super boost, from my point of view it was almost unnoticeable, I don't know other people..?
Now its a really nice paper holder!

Yeah I know PhysX uses the GPU to do physics math, and thats cool, but my point is that CPU cores are growing too, and with the current architecture one wont see any difference by running ones app in a 8 core machine cause its only using 2 cores (my case)... And you could threads some other stuff like AI, Logic and what ever, but later when 16 core machine get here (near future) you will be loosing a lot of parallel power. So thats why new architectures try to think in scalability, to make your app use the cores as smart as its possible, so you don't have to modify your game to be x number core compatible!