sometimes even D3DPOOL_MANAGED resources need to be recreated after device lost?

[shuipi]

I heard some colleagues saying that if a managed resource is in the VRAM when a device lost occures, Reset( ) won't re-copy the sys mem copy of the resource to VRAM, so you still need to manually release and recreate it?

[Sc4freak]

No. Direct3D guarantees that it will be handled and that it will "just work".

In Direct3D10, however, it's even better. There's no such thing as a "lost device", and you don't have to handle it. If your window is minimised, loses focus, etc. Direct3D10 does it all for you.

[armchair_architect]

There's no "lost device" -- but there is now "device removed" :wink:.

DXGI_ERROR_DEVICE_REMOVED: The video card has been physically removed from the system, or a driver upgrade for the video card has occurred. The application should destroy and recreate the device in question.

Much less common though, and just exiting gracefully should be good enough.

[Humus]

I heard some colleagues saying that if a managed resource is in the VRAM when a device lost occures, Reset( ) won't re-copy the sys mem copy of the resource to VRAM, so you still need to manually release and recreate it?

Nope, you don't need to do that. However, the texture won't be immediately reuploaded. Not until it is referenced by rendering code will it be uploaded to video mem. Same thing when you first create it btw.

[mikegi]

Nope, you don't need to do that. However, the texture won't be immediately reuploaded. Not until it is referenced by rendering code will it be uploaded to video mem. Same thing when you first create it btw.
Quick somewhat related question: is a copy of a D3D managed texture always kept in system memory after being downloaded to the adapter? Or does it only exist in one place (system or adapter) at any given time?

Thanks,
Mike

[Demirug]

It depends.

If you are running on Windows XP (XPDM) managed textures will always keep a copy in system memory.

On Vista (WDDM) with D3D9 there is still a copy in the system memory. D3D 10 doesn’t know a managed pool anymore therefore there isn’t any copy.

On Vista + Hotfix KB 940105 or SP1 every texture will only exists once. It will only store in system memory if there isn’t enough room in the video memory. If it need to swap there will be two copy operations necessary. Additional accessing a managed texture can be more expensive with this.

[ERP]

Also of note in DX9 at least is that dynamic resources can't be managed, so they have to be manually restored.

[shuipi]

Nope, you don't need to do that. However, the texture won't be immediately reuploaded. Not until it is referenced by rendering code will it be uploaded to video mem. Same thing when you first create it btw.

To describe me problem more clearly, this is what I saw when I returned to the game from a device lost (by locking the screen): some of the terrain textures appears to be non-mipmapped, and the filter mode appears to be only point sampled. But if I move the camera a bit, some of these textures became normal while others stayed ugly. Could it be that D3D didn't reload all the mip levels to VRAM?

[Humus]

Keep in mind that all states are also reset, so if you are caching states you have to also reset all your cached values. For instance, if you have something like this:

if (mipFilter != currentMipFilter)
{
dev->SetSamplerState(index, D3DSAMP_MIPFILTER, mipFilter);
currentMipFilter = mipFilter;
}

Then you need to reset your "currentMipFilter" variable to the default value after calling Reset().