How I understand, switching texture stops accelerator pixel pipeline (something like jmp misprediction in CPU). While using multitexturing, will it be faster to change only one texture instead of switching all textures (not counting glBindTexture functions overhead)? I believe if pipeline is already stopped, it does not affect performance too much if I will change all textures instead of just one. Am I right?
[This message has been edited by h2 (edited 04-03-2001).]
Architecture dependent question. The answer is as always: Bench it.
Switching less texture units is less work so it might be faster.
Binding a new texture is generally fairly expensive, especially if you’re low on video mem. Sort by texture to avoid changing texture too often. Sorting by material is also a good thing.
Relic
I think too that this is architecture-dependent and even driver-dependent question.
But probably somebody already done some more or less generic observations? Of course I could see what is faster by benchmarking but I’m afraid I cannot do compheresive reseach and will do conclusion based on some concrete version of drivers/videocard.
harsman
Yes, I know that changing texture is expensive. The question is, if I have to change one texture, will be switching texture on another tex.unit be expensive?
BTW I believe app. will not perform nice regardless of the way textures are switched, if you have videomem swapping 
Oh, ok. In that case I haven’t got a clue.
I would do it on a more pragmatic way. If the program design gets easier for you if you switch multiple texture units then do it.
If I look at all programs using multitexturing, on-the-fly updated lightmaps, and even multiple passes, then there is enough to worry about besides how texture units stalls work on different HW.
>>Of course I could see what is faster by benchmarking but I’m afraid I cannot do compheresive reseach and will do conclusion based on some concrete version of drivers/videocard.
Clue: People here will probably enjoy measuring the perfomance if they get their hands on an app which measures it. 