RE: [Algorithms] streaming

[Tom F. <to...@mu...>]

> From: Corrinne Yu [mailto:cor...@ho...]
> > From: "Tom Forsyth" <to...@mu...>
> 
> > Having priority levels for your streaming system really 
> helps smooth out
> the
> > bumps - at quiet times it can be loading more likely stuff in the
> > background, and "just too late" scalable systems allow 
> really busy or
> > badly-predicted times to look bad, but at least stay 
> playable (rather than
> > shuddering to a halt as the disk seeks all over the place).
> 
> -- In my experience with putting together a full streamable 
> (and net file
> data real time in game downloadable) engine now is that 
> priority levels make
> the system very complicated very fast. (I tried that route 
> and end up with a
> giant mess.)
> -- Priority (perhaps your terminology is different or less 
> strict than how I
> am using it here) deals with relative property between resources. In
> streaming, often it is a matter of:
> -- 1. this is what you need
> -- 2. this is when you need it (you guess when)
> -- 3. this is what you don't have
> -- 4. this is how long it takes to get here (always assumes 
> worse case,
> average cases will just make you happy :) )

Yes, I think we're talking about different things. My idea of priority is
simply a guess of how likely you are to need something. So if your streaming
thread doesn't have anything that iit absoloutely _needs_ to load (e.g. the
player is standing still or something), then it loads the thing with the
next highest priority (e.g the next room) as it's "best guess" as to what is
happening next.

You can always boost the priority of things if they get closer. But
priorities are only used when there's nothing that is definately needed - to
do soemthing useful with spare disk bandwidth. If something is definately
needed, it gets "maximum" priority, and the whole thing will obviously stall
until the item is loaded.

> -- It may be simpler to get (in a chunk) what's needed there 
> before you need
> it, even if it is a little "out of order" which you need a 
> little sooner,
> which you need a little later. Have a "chunk" of all the 
> stuff you will need
> at time N, then just stream the chunk in without worrying 
> about whether
> texture A or mesh B needs to get there sooner or later. The 
> logic of this is
> simpler, and you do not have the streaming logic thunking or wobbling
> between streaming in resource A then dumping resouce A back 
> and forth near
> the same time because your "priority logic" is on a borderline value
> (usually happens when running a streaming system on a low 
> memory or low
> resource situation).

No - priorities are never used to throw stuff away - that's just a straight
LRU thing. Actually, at the moment, the game is such that I never throw
textures away - once you have built a room, you are likely to keep looking
at that room periodically. There are cases (e.g. if the room is destroyed by
the enemy), but they are so rare that it's not worth bothering with. Since
the textures are managed by D3D, it handles the actual managemnet - my stuff
just decides whether to bother loading the things off disk in the first
place.

> -- The "chunkness" is "logical" and not "execution time" of course, or
> otherwise you will chunk every time you chunk in your data.
> 
> -- Another clue is that necessary resource may often be geographically
> localized, but hardly always. Can't count on your visibility 
> algos only to
> do streaming predictions for you.
> 
> -- Another good thing about streaming based on "what you 
> need", is when what
> you need changes (which is often, players are _so_ 
> unpredictable), it is
> easy to dump it out and start a new streaming set. If things 
> are already
> inserted into a priority scheme, one has to go through the in 
> queue stuff
> and push their priority back, or actually more efficiently 
> IMO to just leave
> them alone.

True, but you only need to do management of the priority queue when a chunk
is loaded, i.e. you have done a disk seek & load. So you don't get all that
many of them per second, assuming that you haven't split things into chunks
too finely. Fine chunks = lots of work for little benefit. I would rather go
for coarse chunks, and leave the fine-grained management up to the D3D
texture manager or the virtual memory manager as applicable.

Obviously on a console without VM support you need to do something cleverer
- I haven't given much thought to them yet.

> -- (Tom, apologies if I am interpreting your priority scheme 
> in correctly.
> Priority with a large group of data, and not individual 
> resources, IMO may
> work better.)

Indeed - large groups only. Though I do currently handle each texture on its
own, simply because a 512x512 texture is a decently-sized chunk of data
(~256k, compressed + mipmaps - bigger without compression).

> > (hmmm... I seem to have snipped Corrinne's comments out of 
> existence -
> sorry
> > about that - they were good points, and I applaud her daring, I just
> didn't
> > have any comments on them).
> 
> -- Thanks, Tom. I look forward to your own engine streaming work.
> -- (And looking forward to show you mine).

It's a shame I can't retro-fit more streaming into the current Startopia
engine, such as animations (for various crufty reasons). But just
demand-loading (and indeed just-too-late-loading) the textures has almost
halved loading time, which I'm happy with.

> Corrinne Yu


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.