Irrlicht multicore

[yamashi]

Hi everyone !

I wanted to be able to load files while rendering and also get irrlicht to be faster so I started a version of irrlicht multithreaded.
I will make a guest account on my svn the day the engine is fully working.

What works :
Only windows atm.

Engine :

Code: Select all

- Mutex.
- Semaphore.
- Thread handler.
- Core detection.
- SSE extension from 2 to 4.1
- Core use is scalable
- Execution stack

Irrlicht user side :

Code: Select all

- Terrain loading is threaded
- Mesh loading is threaded.

Working on :

Code: Select all

- render threading.
- hyperthreading detection.
- threaded physic calculations.

FAQ :

Irrlicht works fine for me you like wasting your time don't you ?
No I don't like wasting my time, but by the and of the year the we will have CPUs with 20 core ! so we better get started before they get there. The war of who has the most powerfull core is coming to an end it's now who has the highest number of core, we can't count on core amelioration...

How do i get it ?
You can't atm it's not fully working.

Can I help ?
Sure but I have great coding expectations so if you are a beginner with C++ or with irrlicht no need to ask.

When will you release it ?
In about 1-2 months if I work fast.

[omaremad]

Interesting...
How will you handle multithread the pasrts that deal with opengl?

[yamashi]

I found a few articles on opengl multithread rendering, I will see once I am done with the 3 big things I am working on.

[dlangdev]

This is interesting news. Are your also going to look into virtualization of stuff like meshes and textures? That would be nice.

[yamashi]

Maybe I don't know yet depends if i have time or not...
I am doing this for my own needs but it's long and huge so i thought that releasing it would be a good idea to help people with the same needs.

[Halifax]

Yeah, I don't see how/why you would want to multithread OpenGL right now. As far as I know, it's not multithread safe. If you were to multithread OpenGL, wouldn't a separate state machine have to be created for every thread, and synchronized with the other state machines across threads?

I don't know much about OpenGL multithreading, but with OGL2 it doesn't seem to be beneficial to me. It would be cool to see the collision detection multithreaded though, as well as input. That would be cool.

[omaremad]

It really depends halifax, you can still use context switch to multithread a opengl. The problem with not multithreading is during asyncronous mesh loading.... the texture creation in opengl would be slow enough to need two contexts escpecially for larger textures. otherwise you would get pauses everytime a texture is created ( this is irrespective of a texture upload)

Also a very important point is asyncrounous loading would require callbacks and ready flags since you would want you code to do things to nodes / meshes only after they have loaded completely... otherwise you are operating on nothing. Thats why in the my old demo i just did the logic within the actual scenenode rather than changing the engine/ main code too much.

[yamashi]

Actually I don't start a thread to load something I have a certain number of threads depending on the number of core available or the user settings and I have a stack of what to do element so when you call addTerrainSceneNode() the function adds to the todo stack and the thread will take care of it when they get to it in the stack that's why you don't even have to modify your actual code to work with my modifications.
Only one thing to modify, when you are adding all your options texture you have to call registerForRender() because I had to remove it from the constructor so that the render doesn't render while it's not fully loaded.

[MasterGod]

What about efficiency. Using a todo stack for every thread could be nice but would require lots of context switching which could be expensive.

If I understand halifax right, as I have no idea how opengl works, if doing stuff with opengl running in few threads would require many context switches (including adding a todo mission to every thread) because every thread would have its own state machine, then your way of synchronization is very expensive, too expensive in my opinion.

Well, I guess it's also depends on how you define your todo objects.

Ignoring for a second what I said, it sounds like a great idea and I support it very much.

P.S
Having efficient todo objects still don't overcome the overhead many context switching have.

[yamashi]

I don't plan on threading the render API especially opengl since I don't use it...
But my todo list works fine and fast since it's only a tempate container to which I send a structure.

Here is an example of what is looks like :

Code: Select all

if (!parent)
		parent = this;

	if (!heightMapFile && !addAlsoIfHeightmapEmpty)
	{
		throw CException(1,"Could not load terrain, because file could not be opened.",9);
	}

	CTerrainSceneNode* node = new CTerrainSceneNode(parent, this, FileSystem, id,
		maxLOD, patchSize, position, rotation, scale);

    struct TerrainParam;
    TerrainParam.node = node;
    TerrainParam.heightMapFile = heightMapFile; 
    TerrainParam.vertexColor = vertexColor;
    TerrainParam.smoothFactor = smoothFactor;

CThread::getSingleton().send_event(THREAD_LOAD,TERRAINSN,&TerrainParam);

It doesn't take lot of calculations or memcopy and there is critical section because send_event is only 1 instruction.

[Halifax]

It really depends halifax, you can still use context switch to multithread a opengl. The problem with not multithreading is during asyncronous mesh loading.... the texture creation in opengl would be slow enough to need two contexts escpecially for larger textures. otherwise you would get pauses everytime a texture is created ( this is irrespective of a texture upload)

Also a very important point is asyncrounous loading would require callbacks and ready flags since you would want you code to do things to nodes / meshes only after they have loaded completely... otherwise you are operating on nothing. Thats why in the my old demo i just did the logic within the actual scenenode rather than changing the engine/ main code too much.

Hm, yeah, that makes sense omaremad. Thanks for correcting me.

[kburkhart84]

I think your best bet is probably do limit how many threads you have and what they do. Specifically, you only should have one thread for any and all "rendering" operations, as in actual drawing things. Any other threads would be used for physics, collisions, input, sound, and basically everything else, except for loading of "visual" things. Those have to be in the same thread as the rendering, at least if you want to avoid problems. If you are loading into software buffers, than you are probably ok loading meshes while rendering other meshes, but if you are using hardware buffers, you probably can't get away with it so easily. I would say pretty much all else goes though. You could do any physics as long as you weren't modifying verts that are going through a render at this point in time. You would get an effect similar to screen cracking cause by not having V-Sync on your monitor, where some verts or on this part of the animation, and some verts are on another.

[yamashi]

except for loading of "visual" things. Those have to be in the same thread as the rendering, at least if you want to avoid problems.

That's basicly what I want to make possible...
Loading while rendering because my terrain manager loads terrain when you get close and my problem is that when I load a terrain when I am close enough there like a little pause...

[kburkhart84]

Somewhere on the wiki is an example for "endless" terrain by I think it is "Saigami" or something like that. I haven't visited it in a while, but it was an example of how to have an endless terrain that kept a certain amount in memory, and when you pass a boundary loads the next set in line. You might could do somethin glike this in a separate thread, but I'm not sure, considering that you still couldn't access video memory in a separate thread, unless I'm wrong here.

[FreakNigh]

Be nice if irrlicht had its own threads.