I was profiling my engine today. I have to load and unload lots of textures during runtime, there is no way around this. Normally I don't have control over these textures, but for profiling I do control it. For testing purposes, I render my scene and apply the same texture everywhere. First I profiled the system where I created the texture from file 1 time. For each object I made a set texture call, however. I ran the exact same code, but now, instead of creating the texture onece, I call createTextureFromFile for each object. The same scene, the only difference is that in once case I create the texture once, the other case I create it many times. This would affect many parts of the code, which is fine, but what boggled my mind was this: (for thos not familiar with the profiler in MSV6, the fields are total function time, % of total app, func + child time, % of total app, and the number of calls made) Slow code: 1687.947 11.9 1687.947 11.9 2453 -> LockIndexData Fast Code: 278.039 2.6 278.039 2.6 2448 -> LockIndexData Now that's crazy, 1687.947 ms to lock the index buffer with many textures loaded, and 278 to lock the index buffer without. O.k, I thought, what about the vertex lock? Slow code: 2.239 0.0 2.239 0.0 2453 -> lockVertexData Fast code: 0.972 0.0 0.972 0.0 2448 -> LockVertexData There is also a huge discrepancy, but I am not getting hit for vertex lock all that bad, so it really doesn't matter. Why in the world are my index locks gettting hit way more? And what does texture creation have to do with it? I am utterly stumped here. My VB's and IB's are both dynamic. I am creating them with pool D3DPOOL_DEFAULT and locking with D3DLOCK_DISCARD. I'm getting the hang of most of the DX pipeline, and optimizations thereof, but this has got me really stumped. Any ideas anyone? BTW, I do manage my textures. So some get deleted and new ones added. [edited by - ataru on March 18, 2004 8:48:20 PM]

shameless bump

It might be that you''re now avoiding stalls by spending time elsewhere.

Instead of

Lock, Draw, Lock(stall), Draw, Lock(stall), Draw...

You''re now doing

LoadTex, Lock, Draw, LoadTex, Lock, Draw, LoadTex, Lock, Draw...

The difference being the GPU is done drawing by the time you finish loading a texture, so you don''t have to wait for the lock to occur.