Hey Folks,

I've been profiling some C++/Nonmanaged/Direct3D code that is responsible for unloading a large level in our engine. Basically, I've been chasing down a mysterious 12 second spike, and have found around 8-9 seconds just in the following calls:

Call                       Total Seconds Number of calls
IDirect3DTexture9::release      2.781495 2585
ID3DXEffect::release            2.572532 12
IDirect3DVertexBuffer9::release 2.166323 3756
IDirect3DIndexBuffer9::release  0.306574 1304

Clearly we could have some kind of pooling system for VertexBuffers, but that would only give us around 2 seconds.

Whats going on? Is this expected behaviour? Why should any *::release functions stall at all?

Doing resource creation and destruction inside your primary game loop is not recommended. As I don’t know how many minutes of game play your numbers represent I cannot rate this specify values here.

I haven’t check the exact behavior for release but there is a general point about Direct3D resources. As long as a resource is still in the command queue (which can store up to three frames) the runtime can stall if you try to make a direct access to such a resource. An attempt to delete a resource should be qualified as a direct access.

Thanks Ralf,

These timings were for a single frame - inside our primary (render) thread - so yeah its a quite a problem, for example when moving between levels. We really need to keep the render thread going at this point. Do you know how tricky it will be to just pass off the releasing to another thread? Are there any D3D/multithreading gotchas that might make this difficult?

I don't think calling Release from another thread is going to help, because its still going to go back to the device.  Besides, all the D3D stuff needs to be called from the same thread anyway.  The real question is why do you need to call Release during your main loop?  There are generally better ways to structure resource usage so that you can avoid the costly call to create or release resources in the main loop.

I simply need to free the memory allocated by the DX resources to allow a new set of resources to load (for example switching between game levels, while displaying a progress bar). Outside of the game loop or another thread, where else can you suggest we do this? I suggested that calling release() in a non-main-loop/rendering thread would allow it to stall without pausing the main loop. Surely a release() doesn't stall every thread in the process?

blackc4t:

I simply need to free the memory allocated by the DX resources to allow a new set of resources to load (for example switching between game levels, while displaying a progress bar).

If its at level load time, what's the problem with just waiting for it to finish?  You're going to be accessing disk and decompressing textures, models, etc., which are all going to dominate the time for this operation, not calling Release.

That does seem like a long time to me. Are you observing these times in a release (as opposed to debug) build? I'm just wondering if there might be some extra memory tracking going on.

legalize:

Sorry, to clarify our engine is constantly streaming, the "level load" screen is only when starting or switching levels. 

The problem is that I don't want to stall the game for upwards of *one whole second* just to release one D3DX resource. Our phyiscal loading is done in an alternate thread to mitigate that time, and I'm wondering if there a solution to this absurd delay.

 Is it even possible to make a game with DirectX that streams data (effects, textures, geometry) constantly, without these huge stalls?

Roonda:

This is our hybrid build (optimsations on + debug info), using Direct3D set to retail, on a good machine (NVIDIA 8800), using Vista 64. As I said before the times are absurd, particularly when you look at their break down, sorted by time: Effect Release Times