Irrlicht Engine

Hi,

This is created to exchange ideas about how we could implement threading in Irrlicht. The conversation start in this thread http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=38505.

What we discuss here:

- features desire
- possible architecture following irrlicht style

i will post my ideas later.

Hi,

First ideas to discuss

We could create a CIrrlichtThreadManager class and IIrrlichtThread interface to be implemented by every manager that desire execute something in work queue. The CIrrlichtThreadManager this class will be responsable for create real threads based on system processors number. This way we could create change for example the loaders to generate the tasks to be executed in background, we can use loader implementation to create core paging, lod, etc... All implemented on top of this structure.

Do we really need to have this in the beginning? As it was shown elsewhere, it's easily possible to add thread pool parallelisation via OpenMP in the collision manager. I think this is the way to go - identify the places in Irrlicht which are already threadable. And also those places (esp. containers and structures) which are prohibiting threading.
Another thing, which was mentioned in the past and also in the linked post, is loading. I think the way to go here is to add a flag somewhere (driver possibly?) to load only the textures into CPU-RAM. Then do a finalize (and/or automatically on render) from the main thread which takes the images and uploads them to the GPU. This should be possible and won't harm the API and usability.

If you have textures and models already loaded in Irrlicht. Can you draw them in seperate threads? Like for a loading screen or something. What causes the loaders to block?

No, all GPU stuff needs to be made in the same thread. At least that's the easiest and in everal cases also the only way. That's why off-loading the loading into the separate thread is much easier.

Hi,

I tryed simulate multhreading using event based technique to make loading cross frames, but stay isn´t good enogh because of texture load. I now that irrlicht actually is not need of threading support if you a develop a casual games, but i working on a greater game, with bigger scene and i really would like to use irrlicht, i think if we had at least background load of reasource isolating CPU-RAM of GPU operations would be fantastic.

It is possible to load textures in the different thread with opengl (you have to setup two shared contexts) as well as with directx (just specify multithreaded flag while creating the device).
But in case of dx it can affect game performance.
There are several "cheap" tricks that can make loading process smoother: iterative loading with small step, raw textures, overlay window.
Threads can be useful in game logic, audio, network and input systems.

A small brain dump on this subject:

1) Do all operating systems which we support also handle threads, specially embedded ones? If not, we'd have to leave thread creation to the user.

2) There's no point in having more than one disk access thread as IO will usually be the bottleneck.

3) The main places where we'd need threads are places where we'd also need incremental loading. This applies to textures (starting with a single pixel and working our way up the mipmap levels), meshes with LoD and of course custom nodes (LightFeather's terrain is a wonderful example here).

4) Users don't like it! Most of the complaints about Unreal's Engine is that textures and meshes lag behind during gameplay, as they are being streamed from disk. For example look at some of the Mass Effect reviews.

Threading should always be optional, see point 4) as a good reason for this. And disk I/O usually requires much more parsing effort than reading effort. So it can be benefitial to have more threads there as well. We even have many loaders which load the whole file into memory first, and only then start the parsing.
I guess incremental loading would just be the next step. This requires just an advanced loader which provides information in pieces. This would replace the refresh call, and instead provide as much information as possible at the time of rendering. The underlying techniques would be the same, so we can go for the first phase without having the second laid out.

I agree with Hybrid, seperate threads for disk i/o would not help much. I also agree that they should be 100% optional, even the degree of how threaded it is, some platforms (EG: The iPhone) probably support multiple threads but not very efficiently.

I think it might be good to have:
- The main thread for rendering and the game logic.
- The loading thread.
- Phraser threads that are spawned after the loading thread finishes loading the object into the memory. (This might gets merged with the loading thread if the "threading degree" is lower.)

It should also be very simple to switch between threading and not threading (EG: It shouldn't be a process of compiling Irrlicht differently.)

~David

bitplane, I have to disagree with point 1. Do you avoid deving on DirectX because it can't be used on most platforms?

What about if I ran something like, cAudio for example in a seperate thread. Would that be able to use the Irrlicht vectors from getPosition calls? It would also be nice if we could use multiple threads in custom scene nodes... custom scene nodes are done all on the CPU right?

3DModelerMan wrote:What about if I ran something like, cAudio for example in a seperate thread. Would that be able to use the Irrlicht vectors from getPosition calls?

You can pass any data you want between threads as long as they're synchronized properly (look up semaphores for details).

3DModelerMan wrote:It would also be nice if we could use multiple threads in custom scene nodes... custom scene nodes are done all on the CPU right?

Err... Any logic you have in custom scene nodes is done on the CPU - just texture loading, draw calls, and the like are run GPU side.

Hi,

It's nice have discussions about irrlicht threading support, i really would like to have this, but i would like to "over parallelization" things. All we know that thread have a cost. To me thread need stay at low level and controlled by irrlicht as threading build block does, central dispatch of Apple.

We need start simple, think how we could integrate thread in irrlicht without loose performance. May be if we create a work queue at low level and allow that manager post work to be done.

For example: scene manager will load a scene, when a scenenode is located on file it create a work on queue to load images and mesh.

by default our irrlicht thread manager will create one thread per queue and just one queue to be used for background loading.

I think that will be bad if we have to worry if context witch manager several threads.

what you think?

How can you say that threads have a cost and then ask we use them as building blocks? What you describe is more akin to threadlet.