Is it possible to a dual core Irrlicht game?

Guest · Post by **Guest** » Tue Dec 27, 2005 2:25 am

Hi,

I have a dual core AMD x64 4200+ rig. I have a dual x64/win32 boot setup on this system (I would have gone full x64 if it hadn't been for poor firewall support on x64 -- namely, no zonealarm x64 version yet).

I plan to create a game on the x64 platform with dual core support in addition to using shader from my ATI x800 256 MB graphics card.

Basically, I want to put together a proof-of-concept demo (at first, then make a game out of it) that utilizes all three of the aforementioned tech on my rig -- dual core, 64-bit, and shader.

Has anyone attempted this already? I would like to know some of the hurdles involved in such an undertaking.

I've read on this post that x64 is possible for irrlicht. Meaning, one could re-compile the irrlicht library for native x64 support. Here's the readme from the v0.14 release of irrlicht:

Sorry, I cannot provide procompiled binaries for Win64.
Please goto the \source directory, unzip the source.zip file
and compile them yourself, it will cost you about 3 minutes.

I'm going to try to build a x64 version with VS 2005 later on tonight. Then maybe try to build/play around with the shaders tutorial. But I don't see any tutorial/example for dual core.

At any rate, why isn't a x64 bin not supplied with the irrlicht 0.14.0 release I wonder?

sRc · Post by **sRc** » Tue Dec 27, 2005 4:03 am

as for your last question, he doesnt provide a 64-bit bin because he doesnt have a 64-bit machine with x64

bitplane · Post by **bitplane** » Tue Dec 27, 2005 4:27 am

you'll need more than one thread to excersise those cores, and irrlicht doesnt support multi threading. here's an idea... try running two programs at once

Guest · Post by **Guest** » Tue Dec 27, 2005 5:22 am

Thanks all for the replies! I felt like a dork after re-reading the thread subject. Oh, well. That's what I get for changing my mind mid way through typing out the subject title.

bitplane - that sucks that irrlicht doesn't support multi threading.

hybrid · Post by **hybrid** » Tue Dec 27, 2005 11:17 am

Anonymous wrote:bitplane - that sucks that irrlicht doesn't support multi threading.

Now, this does not mean that you can't get any benefits from dual core. You just have to take care on your own for all this thread safety stuff. We have our project multi-threaded in order to avoid blocking I/O. So what about putting physics jobs into a second thread. You just have to make a snchronization barrier into the main loop and update the positions in the main thread.

jclins · Post by **jclins** » Tue Dec 27, 2005 7:14 pm

Thanks, hybrid, for clearing that up. It would be nice if irrlicht supported multi-threading. You could put each of it's different components in a different thread -- gui, io, video, scene, etc.

I wonder how difficult that would be. I've seen so many different version of irrlicht. I can't believe no one has put together a multi-threaded version?

Maize · Post by **Maize** » Tue Dec 27, 2005 10:00 pm

I cant read minds yet so it would be hard to answer your last question.

jclins · Post by **jclins** » Tue Dec 27, 2005 11:36 pm

Maize -- I'm not sure what you mean.

Hybrid -- I was going to ask you what "blocking I/O" means but found this link via google that explains it quite well:

http://www.artima.com/articles/io_design_patterns.html

hybrid · Post by **hybrid** » Wed Dec 28, 2005 11:15 am

I think that a multithreaded Irrlicht would need rather high efforts to get it running. From the proposed components I'd choose GUI to get a separate thread. But whenever you do rendering from different threads to the same buffer you have to interleave these render phases sequentially. Thus, you won't get any benefits for render time, only the response time to button clicks could be improved.
So instead of separating complete components it would be better to split the I/O system into a different thread (as written in my previous post). You could put file I/O into one thread, but usually this does not help very much (maybe a little when loading many meshes for a new level, I don't know if lots of calculations are needed to setup new meshes). The event system should also be put into a separate thread, this should help a lot. You'd need an event receiver which sleeps until events arrive. Event handling would be done in a separate thread, but the effects of event handling might need additional synchronizations with the main thread. So you might need several thread synchronizations and change a lot of the Irrlicht code. Maybe putting add-ons into separate threads is best for the moment.

hybrid · Post by **hybrid** » Thu Dec 29, 2005 2:39 pm

I think I found a very promising way of multithreading all Irrlicht components. It's called OpenMP and compiler support is growing. Currently Intel and Microsoft have built-in support for it, while gcc users have to wait for gcc 4.2 or use a branch of the current version.
OpenMP uses a fixed number of worker threads which are always available. You can instrument your code with parallelisation markers (using pragma commands) which tell OpenMP to, e.g., parallelize a loop. This way you can easily parallelize many expensive calculations without having any problems with synchronization or thread creation penalty. Of course you cannot parallelize as much as a truely multi threaded application would have.

jclins · Post by **jclins** » Thu Dec 29, 2005 9:08 pm

hybrid -- wow, that is intriguing. I didn't know they had such a standard for multi-processing. I thought the windows platform utilizes multi-threading while the unix/linux platform uses multi-processing?

You mentioned support of OpenMP built into microsoft's compiler. What version exactly? VS .Net 2003? VS .Net 2005?

I guess I could just try adding a pragma and see what happens.

If anyone else is interested, here's an FAQ from the officila OpenMP web site:

http://www.openmp.org/drupal/node/view/11

One wonders if the development kit for the xbox 360 uses OpenMP standard? That would be logicial, but I guess there's no way to find out. I'm wondering this as to see how effective the standard is on a commerical software program.

Oh, and the spec is here:

http://www.openmp.org/drupal/node/view/8

I just skimmed through the May 2005 C++ OpenMP spec. I can't say I like using pragmas directive inside a code is all that pretty. It's akin to seeing a bunch of #ifdef inside the code. The more of them present the more it clutters the code -- making it less and less readable. But that's just me.

Thanks hybrid for pointing this out to everyone here. There is hope yet.

hybrid · Post by **hybrid** » Fri Dec 30, 2005 10:54 am

jclins wrote: You mentioned support of OpenMP built into microsoft's compiler. What version exactly? VS .Net 2003? VS .Net 2005?

It's the 2005 version, but not the express, only commercial ones come with OpenMP support (IIRC). But I'll stick with Intel's icc as that's free for Linux.