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?
// 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
Now, one must wonder how ppl. cope with dynamic content faced with those limitations.
There are potential mis-usage scenarios like:
any artist / designer / gameplay activation/deactivation of additional render target(s)
delayed GLSL shader creation
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…