[Tom9729]

Hey guys,

I'm working on async/background resource loading for my engine so I can load stuff on-the-fly, or at least show a loading progress screen. Admittedly I haven't researched this too thoroughly, so feel free to scold me.

My system is using the concept of worker threads that pull jobs (basically filenames to load) off a queue.

Does it make sense to have more than one worker (thread) active at a time? Am I right in thinking that the disk is going to be a bottleneck, and that trying to load a bunch of files in parallel is just going to mean that they all finish around the same time?

Of course, I'll do some experimentation when the whole thing is a little more complete. Was just hoping someone could throw in their 2 cents.

[ButchDean]

How do you decide what you are going to load when during gameplay? It is perfectly conceivable for the player to rapidly move in and out of zones where the loading of resources may be frequently triggered.

Parallel resource loading is a bad idea. You might what to look at streaming resources as the player moves around large areas, but honestly this is all unlikely to be worth it; on paper it looks good, but I know you will run into problems in practice.

[Tom9729]

I'm actually talking pretty low level for now.

Basically I have a LoadResource(filename) function that calls the appropriate loader for the file you're trying to load and blocks until it's loaded. This is running in the same thread as the GL context so for big files this would basically freeze the game. This is unacceptable regardless of whether I'm trying to implement seamless loading as the player moves between levels or just throw up a simple loading screen.

Now I have a PrefetchResource(filename) which returns immediately, and spawns off workers/threads to load the resource in the background. LoadResource(filename) checks for the prefetched resource, and blocks until it has been loaded (hopefully by the time we get here, it is already loaded and we can return immediately).

What I'm really asking is: will there be any benefit to loading files X, Y, Z at the same time in 3 separate threads (as opposed to loading X, then Y, then Z)?

Edit: Is this just a case of parallel = higher latency, higher throughput?

This post has been edited by Tom9729: 02 August 2011 - 04:54 PM

[ButchDean]

Pretty much like I said before, it's bad idea. The purpose of a threads is to perform relatively small tasks in parallel - in that you have one big serial process that is broken into smaller parallel ones. What you are proposing in to have (at least potentially) large tasks running in parallel, which won't benefit you. Can you see where I am coming from?

Also you still haven't pointed out what criteria you will be using to trigger your load resource threads, and what guarantee do you have that the resources will still load in time for use in the game?

Just stick with loading X, then Y, then Z - I am pretty sure your solution will not work. Also as I already pointed out, if it bothers your that much then look at resource streaming, which is pretty much used in free roam games like GTA IV where there are no loading screens as you drive around.

[Tom9729]

ButchDean, on 02 August 2011 - 08:09 PM, said:

Pretty much like I said before, it's bad idea. The purpose of a threads is to perform relatively small tasks in parallel - in that you have one big serial process that is broken into smaller parallel ones. What you are proposing in to have (at least potentially) large tasks running in parallel, which won't benefit you. Can you see where I am coming from?

Also you still haven't pointed out what criteria you will be using to trigger your load resource threads, and what guarantee do you have that the resources will still load in time for use in the game?

I want to load n-many files of varying sizes and types. I can use them as soon as they are ready. The idea is to be somewhat optimistic and prefetch files I *think* I'll need; they'll just get tossed in a LRU cache and then really no harm done if I end up not using them. If I *need* to use a file and it hasn't been loaded/prefetched yet, I can either use some kind of placeholder until it is ready, or I can stop and wait for it to load. I understand that reading from the disk is ultimately a serial operation but I think it might be advantageous in situations where a bunch of little files that we need immediately are stuck waiting for a big old whatever to load.

Anyways I think I sort-of answered my own question, and this stackoverflow post seems to confirm what I was thinking.

[ButchDean]

Tom9729, on 03 August 2011 - 03:38 AM, said:

ButchDean, on 02 August 2011 - 08:09 PM, said:

Pretty much like I said before, it's bad idea. The purpose of a threads is to perform relatively small tasks in parallel - in that you have one big serial process that is broken into smaller parallel ones. What you are proposing in to have (at least potentially) large tasks running in parallel, which won't benefit you. Can you see where I am coming from?

Also you still haven't pointed out what criteria you will be using to trigger your load resource threads, and what guarantee do you have that the resources will still load in time for use in the game?

I want to load n-many files of varying sizes and types. I can use them as soon as they are ready. The idea is to be somewhat optimistic and prefetch files I *think* I'll need; they'll just get tossed in a LRU cache and then really no harm done if I end up not using them. If I *need* to use a file and it hasn't been loaded/prefetched yet, I can either use some kind of placeholder until it is ready, or I can stop and wait for it to load. I understand that reading from the disk is ultimately a serial operation but I think it might be advantageous in situations where a bunch of little files that we need immediately are stuck waiting for a big old whatever to load.

Anyways I think I sort-of answered my own question, and this stackoverflow post seems to confirm what I was thinking.

Remember that you are trying to do all of that whilst a game is running, and depending on the game's complexity, it might have threads doing other stuff. The stackoverflow link you provided makes no mention in the context of game programming, and even with standard applications there is caution against using such an approach.

I'm going to be blatantly honest here and make the clear prediction that this is something you cannot get off the ground, it simply will not work as part of a game engine. I hope you prove me wrong.