I’ve just seen a “strange” and reproducible problem and I wonder if anyone else did see it as well -
a performance meltdown 80FPS -> 7FPS on NVIDIA hw. if I allocate a large (2048) shadowmap texture after loading level textures / VBOs. If I allocate the shadowmap up front, all goes well and merry.
Does it sound like a known limitation, texture swapping symptome or a driver bug?
HW: NV 6800LE, 128MB, ForceWare 84.43
// GeForce_6800_Performance.pdf
//Order of resource allocation affects performance
// Allocate render targets first
// Sort order by pitch (bpp * width)
// Sort pitch groups by frequency of use (most used first)
// Then create vertex and pixel shaders
// Load / create remaining textures
// GPU Programming Guide.pdf
//Allocating Memory
// In order to minimize the chance of your application thrashing video memory, the best way to allocate shaders and render targets is:
//1. Allocate render targets first
// Sort the order of allocation by pitch (width * bpp).
// Sort the different pitch groups based on frequency of use. The surfaces that are rendered to most frequently should be allocated first.
// 2. Create vertex and pixel shaders
// 3. Load remaining textures@CatAtWork: Thanks, that was quite useful. 
Now, one must wonder how ppl. cope with dynamic content faced with those limitations.
There are potential mis-usage scenarios like:
I suppose those are solvable at memory pre-allocation cost & shader cache pre-warming cost (or scene reloading cost in content creation) and some very careful planning on render targets reusal. Anyways, abstractions like OpenGL require performance tradeofs…
yeah cheers for that IIRC im doing, shaders->texture->rendertargets i’ll swap it around