I have my basic system setup which can handle both window resize (CreateAdditionalSwapChain method) and also lost-device which re-creates all the vertex buffer. Now i am wondering for a large DX application which may have hundreds of mesh data read from files and also hundreds of textures and etc..When a device is lost and all the vertex buffers are recreated they need to be filled with all the mesh data and texture data one more time.. which is basically equivalent to loading the application from scratch. One solution could be to keep a system memory copy of all the data.. which actually doubles the memory requirement.. so how does large DX application handle these type of situations ?

For static meshes, you can create your buffers / textures in the managed pool, and then you don't need to recreate them on lost device. You only need to recreate resources that were created in the default pool (well, maybe some other resources, but you don't need to recreate managed resources)
Check the D3DPOOL_MANAGED creation flag.

I'm not that experienced with large DX applications, but most of the time I try to stay away from the Managed memory pool and stick as much as possibile in the Default pool. This will remove the memory requirement to back all managed resources with system memory and you don't have to distinguish between managed and unmanaged resources.

Additionally you'll have more control over your resource (re)loading, allowing you to show some kind of progress indicator when the device is lost/reset and resources need to be reloaded. It's a bit of extra work, but it looks a lot better than having your app stop responding while managed resources are being reloaded by the runtime.

I don't know if this is a recommended or even elegant approach. Obviously the Managed pool was created for a reason and I'm a bit reluctant about not using it, but it feels a bit like a crutch at times. Any comments on this would be very welcome :)

Quote:But I very much doubt you'll be able to create a more efficient resource manager than the DX team have managed.

Thanks Steve, there's no doubt in my mind whatsoever that I'm quite incapable of coming up with anything even half as efficient [smile]

I think you're right that commercial games do mainly use the managed pool, which is why I brought up the app not responding issue. In Halflife 2 for example, triggering something that reset the device resulted in a loooong wait while the game was reloading resources, all the while looking at a frozen screen wondering if it wasn't hanging. By 'manually' reloading resources into the default pool, you could just go over a list and show some progress indicator that the game is actually still doing something. It's a small thing, but it kinda detracts from the enduser-friendliness of the Managed pool.

As for normal resource management, even with the managed pool you'll still need to keep track of the resources you need to have loaded for single frame. True, you won't have to worry about the physical transfer to and removal from videomemory, but you still have to load them in the first place and unload them whenever they're not needed anymore. If your game consists of scenes or areas with neatly defined resource requirements, I don't think there would be a big difference between using the managed or default pool. Meanwhile, you'll always have the system memory backing requirement for the managed pool.

I'm not trying to be a stubborn ass here (which I probably am anyway [wink]), just wanted to explain where I'm coming from with my mad idea of not using the managed pool.