texture speed questions

  1. If I have 3 polygons with 3 different textures, what will be the fastest way to draw them:

a) Create 3 textures, and then for each frame, bind texture A, draw polygon A, bind texture B, draw polygon B, bind texture C, draw polygon C.


b) Create 1 blank texture, bind that texture, and then for each frame, glTexSubImage2D the image you want displayed on polygon 1, draw polygon 1, glTexSubImage2D the image you want displayed on polygon 2, draw polygon 2, glTexSubImage2D the image you want displayed on polygon 3, draw polygon 3.

In method a) there’s a lot of binding going on, but in method b) there’s a lot of copying to texture going on. I would guess that method a) would be faster because in method b), you’re copying data from system memory to video memory, but then again, I don’t know what the cost of binding textures is.

  1. With modern-day video cards, or even those a couple of years old, is it significantly slower to draw a textured polygon than an untextured polygon? I mean, it may not make any practical difference for 1 polygon, but what if you were drawing thousands of polygons per frame, say 100,000? Then would you start to notice a significant difference in speed?

Method a.
Copying all three textures over and over again is redundant and does nothing but waste precious bandwidth.

It depends on your filter settings, trilinear costs twice the fillrate on most modern chips (Gf2 - GfFX, R200, R300, maybe R100 too?). But don’t hesitate. Textures are IMO ‘fast enough’. If you use a bilinear mipmap filter, the only thing you lose is texture bandwidth, and thanks to good texture caches, you’ll hardly notice any slowdown. The texture sampling itself is ‘free’, ie the hardware that does it can’t be used for anything else anyway.

Also, texturing really is your friend. Think of it as a fast way to add flat surface detail, that would otherwise have to be created with colored geometry (at a lot higher price in terms of performance).

Also take note that the performance impact of texturing (if any) doesn’t depend on the number of primitives, only on the number of samples (or in other words, the number of pixels covered by primitives).