Jump to content
  • Advertisement
Sign in to follow this  
Lutz

Asset streaming, paging and hitches

This topic is 3347 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, I'm using a streaming system in my C++/DirectX9 app on WinXP to load most assets (textures, models, level data, ...). Buffer memory for loading files is allocated dynamically and so is memory for most assets (textures for instance are allocated separately and in most, but not all cases, the file data is just copied into the texture). Even though loading is supposed to be perfectly asynchronous, I'm still seeing hitches. Those can be very large, several seconds in rare cases. A look at the Windows XP performance monitor (in the task manager) shows me that when a hitch occurs, the CPU usage drops and the page file usage increases. Thus, it doesn't seem to be a threading issue (as I first assumed), but a problem with virtual memory paging. Also, my whole system hitches, not only my app. If it were a treading/locking issue, only my app would hitch. The size of the memory allocated during a single async io job can total 20MB - 30MB (temp buffer for file reads, all textures, models etc.), so what I assume might be happening is that Windows is going panic since it sees a large amount of memory allocated in a small amount of time and starts paging other app's memory to disk, so that my app has a bigger memory slice. I'm using unbuffered, overlapped IO. Not sure if that's related. The memory for the IO reads is allocated via aligned_malloc and the memory for the assets uses the standard malloc. So I'm wondering: - Are there any good references for implementing a streaming system? I think I have the very basics convered, I need some advanced reference dealing with proper memory management and such. - Did you run across a similar problem? If so, how did you solve it? - In particular, do you think a private, pre-allocated memory pool for IO reads would solve the problem? Thanks in advance for your help, - Lutz

Share this post


Link to post
Share on other sites
Advertisement
Unbuffered overlapped IO as you do it is the right thing for streaming (though personally I don't think it's a good solution at all).

What you describe sounds to me like the OS is creating a new swap page and is fighting over the hard disk with the asynchronous IO (though obviously it's impossible to tell). So, to solve that issue, you could try to prefault your memory (by writing a byte in every page, for example) before starting IO. Or, as you mentioned, use a fixed-size memory block.

I use overlapped, buffered IO in IOCP-controlled worker threads myself, which I find a much better solution than the "correct" one.
This will run asynchronously often, and block sometimes (in a worker thread). It won't be zero-copy-DMA (which I honestly give a crap about!), but it will make use of the buffer cache. Buffer cache is a good thing, especially under 32 bit OS with a somewhat limited address space. On my machine (and figures are probably similar everywhere) pulling data out of the buffer cache delivers upwards of 800 MB/s.

In all honesty, I can't understand what operating system designers (Windows and Linux likewise) thought when they implemented asynchronous IO. There seems to be no notion of a thing as simple as "load it in the background as efficiently as possible, I don't care what you do, just let me query whether it's done -- just for Christ's sake, don't block".
Somehow, asynchronous always has to mean "incomprehensible, alignment issues, and either unreliable or no buffer cache" for the minor benefit of doing DMA transfers and saving one memcpy() which is really insignificant compared to the gains of pulling pages out of the buffer cache. And sadly, the unreliability is even worse under Linux than under Windows. You only notice when queuing your "asynchronous" requests suddenly takes 15 milliseconds :(

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!