I've come across some rather odd behaviour in my game that seems to be related to using D3DPOOL_MANAGED textures. I have several textures in use in the game, one for the background, one that atlases map blocks, and textures containing my GUI font and my console font. When the game runs, I get a frame rate of 75 (vsynced). However, when I first open the menu or the console, and the font textures are used for the first time, the frame rate drops down to about 35. Now the next paragraph is the important bit: The weird thing is that it stays at 35 after I close the menu or the console. The even weirder thing is that if after this has happened I call a device Reset(), the frame rate rockets back up to 75 again, regardless of whether the menu or console is open, so the hardware is obviously quite capable of holding all the textures in video memory at the same time. It seems to be something to do with the textures being brought into vram the first time. I have solved the problem by making the font textures D3DUSAGE_DYNAMIC and D3DPOOL_DEFAULT but obviously I now have to manually recreate them on a Reset(). This is not a problem at the moment, as my font loading is quite fast, but I am interested in finding a better solution in case I end up having to use this approach with resources that are more expensive to recreate. Is there any way to force a D3DPOOL_MANAGED resource into vram without actually having to do some rendering with it? Any other thoughts or ideas? Thanks.

It sounds like you've hit a state such that the runtime wants the managed font texture moved into VRAM, but has decided it also needs to move it out mid-frame. It's the sort of behavior I'd expect if you were close to using up all of your VRAM. However that doesn't sound like the case, since you've said you only have a few textures. I suppose NVPerfHUD or the ATI equivalent would be able to tell you for sure.

Quote:Original post by MJP
It sounds like you've hit a state such that the runtime wants the managed font texture moved into VRAM, but has decided it also needs to move it out mid-frame. It's the sort of behavior I'd expect if you were close to using up all of your VRAM. However that doesn't sound like the case, since you've said you only have a few textures. I suppose NVPerfHUD or the ATI equivalent would be able to tell you for sure.

Yeah, I thought it was probably thrashing the texture in and out of vram, but it's weird that it stops after I reset the device.

Guess it is going to remain a mystery [smile].

Quote:Original post by Namethatnobodyelsetook
All D3D resources have a "PreLoad" method, which tells the driver that it should upload the vram, even without a render. It is free to ignore you though.

Thanks. I'll look into that.

[EDIT]

Yep - that solves it. According to the docs, PreLoad() will only fail if there isn't enough room to fit all the resources in vram, in which case thrashing is going to occur whatever and frame rate will plummet.

Based on the above, this isn't the issue here, so this is a perfect solution.

Thanks.