Streaming load features for IRRlicht...

rogerborg · Post by **rogerborg** » Sun Jul 06, 2008 10:26 am

It's interesting reading, but since only one thread at a time should be accessing the hard drive, I can't see many use cases for spawning a multitude of threads.

christianclavet · Post by **christianclavet** » Sun Jul 06, 2008 7:48 pm

Hi, Guy! Thanks for the comments! I've seen lots of constructive ideas to improve the engine we love so much!

Nice ideas Hybrid! If this can be done using that method. It's at least a first step in that direction and would improve a lot the response from IRRlicht when loading things (And would allow us to show something "running" to the user while it's loading.) We'd need also to do this in scene loading. (As we could put some info on the progress as we are loading the scene). For my current test levels, it's taking too long to show something now and really look "frozen".

The streaming load technique could be added as a second step as currently not all engines support streaming loading (would be very useful on some console port because they have to take more of the game assets from the DVD (Example: HALO 3). If you take for example the source engine can monitor the files being loaded but the engine cannot stream assets (as the current engine)

For spawing multi threading only on loading, yes, that wouldnt be that useful(Unless your assets are on multiples drives). But if this could be used for (area of application i'm thinking of):
- Processing the OCCTREE generation (as tested by Blindside)
- SAVING images (screenshot)
- Using the animators codes in threads (collision response, spline animator, etc)
- Particles system
- Calcultating the FRUSTUM CULLING, and OCCLUSION CULLING, and PORTAL (If those were to be implemented)
- Processing the shaders

On a single CORE system, this would not make such a difference, but most system today are at least dual CORE. (Mine is a QUAD as was not really expensive). This would be very nice. But my main preocupation is the loading and "freezing" time associated with it. Those "goodies" could be added later.

dlangdev · Post by **dlangdev** » Tue Jul 08, 2008 5:19 am

here's a video chat about multi-core programming.

http://developer.amd.com/documentation/ ... hchat.aspx

eventually, multi-core will become standard.

dlangdev · Post by **dlangdev** » Fri Jul 18, 2008 9:22 am

hey!

you know what?

i've been playing with tbb ( http://www.threadingbuildingblocks.org/ ) mostly their sample programs, and it turns out there are improvements with respect to performance, some of them having at least twice.

when i'm done studying the sample programs, i'll move ahead and setup several test programs using irrlicht io classes. put a tbb wrapper around them and see how they perform in parallel.

it would be nice to have a chart showing perf numbers on mesh loading, given one thread or task per mesh, i'm sure some threads will block since they will take turns doing disk i/o, but the interesting part is they will be taking turns, interleaving.

so yeah, i think streaming content to CMeshCache is very much possible, provided CMeshCache is re-written to be lock free using tbb containers.

hybrid · Post by **hybrid** » Fri Jul 18, 2008 3:28 pm

Note that TBB is GPL, so no chance to include it into main Irrlicht...

Nox · Post by **Nox** » Thu Feb 05, 2009 1:07 am

Sorry for reanimating this topic, but what about preload methods?
Requirements? 2 threadsafe queues + 1 workerthread. I.e. PreloadMesh get a filename or a IReadFile, put it into the input queue. The workerthread gets the input loads the mesh and save the IAnimatedMesh* together with the filename in the output queue. The IrrlichtDevice::run method checks if there are entries in the output, puts them into the MeshCache (with MeshCache->addMesh) and all are happy. Okay you would have to check if the Mesh exists allready before adding it, but this would not a big deal.
I could only provide a simple securelist for linux and windows (used and tested by my networklib). But implementing such would not a greate issue or did i miss a pitfall?

(i hope that the loaders dont access/use other components of irrlicht)

sudi · Post by **sudi** » Thu Feb 05, 2009 2:20 am

u missed the texture pitfall. when loading a texture not in the main thread the texure is not uploaded to the graphicscard (dunno if this is only the case with openGL) so u will have to make the same thing for textures.

Nox · Post by **Nox** » Thu Feb 05, 2009 9:28 am

I did not miss it

. For textures it is just 1 step complexer because createDeviceDependentTexture is called in loadTextureFromFile. So we could only outsource the createImageFromFile-call in a workerthread but it would work like for meshes.
(does anybody know if opengl is threadsafe for calls from different contexts? DX9 is threadsafe if we create the device with D3DCREATE_MULTITHREADED).

EDIT: of couse we would have to mind the vertex- and indexbuffers of meshes

hybrid · Post by **hybrid** » Thu Feb 05, 2009 9:39 am

No OpenGL doesn not allow context changes from other threads. And D3D will probably lose performace when implicit mutexing occurs. So no, it's not that simple.

Nox · Post by **Nox** » Thu Feb 05, 2009 3:38 pm

So we could outsource the createImageFromFile- and the createMesh-call (if these calls do not use any globals or interact with the graphicdevice indirectly).

thats not much but may be enough.

sudi · Post by **sudi** » Thu Feb 05, 2009 8:50 pm

actuylly the texture would just need a flag that tells the engine if the texture is already uploaded to the card. this has to be checked when the texture is bound before rendering. dunno if this will hit the performance.

Nox · Post by **Nox** » Fri Feb 06, 2009 7:49 am

Hmm CAS flags would be an other options but what is about a getSize call by the user before finished loading or something like this? With preloadmethods we would have the problem, that an object could be loaded in back- and forground simultaneously. So the preloads would have be handled with care. Or we load everything with preload and let the user the decision to block an get-call or to leave if the object is not loaded allready.