using the Quad core

[omar shaaban]

Simply , how to create my application as to use the 4 cores?
not just in irrlicht but in general, how to tell my program to use the 4 cores to speed up the process instead of one ?

[Brainsaw]

This is where multithreading comes in which can be quite hard.

[mongoose7]

Just create four (or more) threads. But OpenGL is single-threaded and, as you appear to be a noob, you will have no end of trouble. But just search this forum for "multithread" or "multythread" and look at the questions others are asking.

[3DModelerMan]

I'm working on using a thread pool. Look up thread pools on wikipedia. They are scalable, so they use 2 threads on a 2 core CPU, 4 on a 4 core, 6 on a 6 core, and so on.

[omar shaaban]

@mongoose7:actually i was asking how to do mutli-threading <admin note: rest got zensored for violating etiquette>
@3DModelerMan: i will look into it thanks

[omar shaaban]

@mongoose7: u will not talk again in this forum, or u will get insulted...... really insulted NOOB

[Radikalizm]

Could we act like mature people here, guys? These insults are completely unnecessary and childish, so please keep them to yourselves (yes omar, I saw what you wrote before it was edited out )

[Granyte]

I'm working on using a thread pool. Look up thread pools on wikipedia. They are scalable, so they use 2 threads on a 2 core CPU, 4 on a 4 core, 6 on a 6 core, and so on.

any more details on your implementation you can share?

i mean irrlicht is not thread safe and i had so much fum just making sure the thread i was using for bullet and the one i was using for irrlicht would not be writing to the same resource at the same time

i mean how to make sur non of your 4 thread working on the diferent task won't just try to use the same resource at the same time

[3DModelerMan]

I haven't done that much on the thread system actually. I haven't threaded enough to where I need to worry about that yet.

[Granyte]

i see it took me 3 line of code to find out about this problem

[shadowghost21]

Threading can be a complicated problem. But as long as you are locking your shared objects you should be fine. I think you might be modifying most parts of irrlicht if you do though, since I don't think it's thread safe. What you want to do it queue up events/actions/changes in a priority queue and then batch them to the respective managers during their turn in the game loop. That way you can avoid any race conditions which I think in c++ might cause some really nice crashes with exploding memory modules.

[Granyte]

it does give some nice crashes but ya to use threading properly one would have to rewrite irrlicht almost entirely

so what i do for now is basicaly i run task that use diferent pools of data concurently and the more complex my game becomes the more of suck data pool are created so my thread have less then less time left doing nothing

i just hope it will be updated to be thread safe during my life time (that hope is there with dx10-11 and compute shaders)

[devsh]

okay... from my experience of paid work and threading...

Irrlicht threaded is FINE as long as:
a) You do not use smgr,driver etc. unless you lock mutexes
b) You're FINE CREATING OBJECTS WHICH ARE NOT LINKED INTO irrlicht pools. I.e. loading software textures in separate threads, AND THEN making hardware textures in main threads work FINE.
You can read mesh buffers JUST FINE (as long as not "getMesh()" because that tries to load textures), file I/O works fine but fileSystem need a rewrite for Async I/O otherwise it will be marginally faster I/O, you can create octrees etc. fine as well. You can do all your physics and crap in multithread as long as you place a mutex around translate, scale and rotate matrix.
c) It would be best practice to have one thread for JUST loading textures, JUST loading meshes, JUST creating stuff for all Irrlicht related things.... this will prevent problems which arise when two threads try to add a mesh pointer to the loader meshes array (very, very rare because it would have to happen AT EXACTLY THE SAME TIME).

[Granyte]

actualy doing physics in a thread require some sort of mutex itself because when the physics update a node position while smgr->drawall() is runing you will still get a wonderfull crash

i wonder if a dynamic lod could be written to run in the background and update the mesh betwen the renders

[devsh]

yeh you could update mesh in separate thread if the hardware hint is EHM_DYNAMIC