PDA

View Full Version : Texture state changes no more expensive?



LaBasX2
09-25-2002, 10:55 AM
Is sorting your polygons by textures still necessary or useful? I always thought so since doing this had an great impact on performance on my old Banshee a long time ago. But calling glBindTexture on a GeForce3 many times doesn't show any performance drop in the framerate. Is binding textures on modern cards for free now?

Thanks
LaBasX2

Bob
09-25-2002, 11:11 AM
Free? Certainly not! You should still sort by texture if possible.

Korval
09-25-2002, 03:57 PM
Is binding textures on modern cards for free now?

Regardless of what they do in drivers or hardware, there will always be certain performance hits. If the texture isn't resident, it must be made resident. Also, you will likely lose the information in the on-chip texture cache, so going back to the first texture may be slower than if you had sorted.

That being said, there are lots of other potential bottlenecks in binding a texture too. Bottlenecks which are probably solveable, via either drivers or hardware.

I, too, have been wondering how bad state changes are these days. In particular, are some state changes (say, vertex program state) better than others?

LaBasX2
09-26-2002, 01:08 AM
Ok, thanks for your answers. I will still continue sorting my faces by texture. I was just wondering that although I was heavily reducing the texture state changes in my engine, I didn't get any noticable performance advantage. But if you want to use vertex arrays the texture sorting is of course still necessary so that you can get groups of faces.

LaBasX2

pATChes11
09-26-2002, 10:42 AM
Then maybe the rest of your computer (CPU, memory, others?) is the limiting factor in your program's performance?

jwatte
09-26-2002, 08:23 PM
Changing between vertex shaders and fixed function is fairly expensive.

Enabling/disabling OpenGL states in fixed function pipelines is moderately expensive.

Re-binding a texture that's already ready on the card is fairly cheap.

What I would do would be sort my objects roughly front-to-back, and then group by state in general (which means lighting or not is as important as what the texture is). That should be reasonable performance.

An alternate approach would be to sort by shader, and then draw each element for that shader front-to-back.

mcraighead
09-26-2002, 09:07 PM
I'd rather see apps sort front to back than by any other criterion.

If your shaders are sufficiently expensive, you may even gain by drawing a Z-only pass (which itself should be front-to-back). Occlusion queries can be used to great effect here.

- Matt