-
Texture switching
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).]
-
Senior Member
OpenGL Guru
Re: Texture switching
Architecture dependent question. The answer is as always: Bench it.
Switching less texture units is less work so it might be faster.
-
Advanced Member
Frequent Contributor
Re: Texture switching
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.
-
Re: Texture switching
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
-
Advanced Member
Frequent Contributor
Re: Texture switching
Oh, ok. In that case I haven't got a clue.
-
Senior Member
OpenGL Guru
Re: Texture switching
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.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules