Sign in to follow this  
browny

lost device code path and vertex buffers

Recommended Posts

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 ?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
Quote:
Original post by remigius
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.
And you have to deal with managing the GPU memory efficiently.

Quote:
Original post by remigius
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.
You'll have to deal with the app not respondong if you use the default pool too - and you have to make sure that for any given frame, all of the required textures are uploaded to the GPU, or you'll end up with missing textures

Quote:
Original post by remigius
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 :)
Use the managed pool [smile] It's there for a reason. If, after profiling your app you find that using the managed pool is a bottleneck, then you can try and work around it. But I very much doubt you'll be able to create a more efficient resource manager than the DX team have managed.

You could run some D3D hooking program on some commercial game (Although I don't know how legal that is), and I'm pretty certain you'll find that almost all the resources are created in the managed pool.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this