what does texel per second mean?

Started by
19 comments, last by kburkhart84 18 years, 6 months ago
Without the intent of derailing the thread, the Wikipedia articles on Mipmaps and Texture mapping go a bit more in depth. I reference Wikipedia only because 3d texturing is such a modern subject that many other reliable sources don't have sufficient information yet. Just finished reading them myself for clarification. Apparently my original answer explains things fairly well.
{[JohnE, Chief Architect and Senior Programmer, Twilight Dragon Media{[+++{GCC/MinGW}+++{Code::Blocks IDE}+++{wxWidgets Cross-Platform Native UI Framework}+++
Advertisement
So basically I can assume that a higher texel per second value means that it can render the texture to the screen much faster. So if this is true, thus this imply that a higher resolution texture can decrease the texels per second using the same screen size?
Quote:Original post by sriniatig
So basically I can assume that a higher texel per second value means that it can render the texture to the screen much faster. So if this is true, thus this imply that a higher resolution texture can decrease the texels per second using the same screen size?


No. The higher the texture resolution the more memory bandwidth is being used.
"C lets you shoot yourself in the foot rather easily. C++ allows you to reuse the bullet!"
Quote:Original post by moeron
I believe it is basically saying how many triangles can be textured per second. (I could be mistaken about this)


That's not what I remember. Your right on most counts, but texels/second (as far as I know) has nothing to do with the number of polygons (except of course because of overdraw). It has more to do with the resolution, because a texture (or several) will be looked up for each pixel. The texel/second rate will probably change depending on texture size. This is because of the cache - when a texel is looked up, neighbouring ones are cached (as they will probably be needed in a moment). If the texture is high resolution, these cached texels will only be looked up by a few pixels, and so not much will be gained. This actually has to do with how large the texture appears on screen too. So, to re-iterate:

Things to do when your texel/second rate is too low and is giving you bad performance:
1. Lower your resolution
2. Use multi-texturing less
3. Lower the texture detail
4. Use mipmapping (actually, do it anyway, it looks better. But the reason for this one is also to do with the cache).
___________________________________________________David OlsenIf I've helped you, please vote for PigeonGrape!
How can graphics cards list their performance in texels per sec if the size of the textures being used has an effect of this value?

I thought texels were textured pixels and therefore texels per second was the number of textured pixels rendered in 1 second. This would mean that no matter what the screen resolution or texture size, the texels per second would not change but the amount that are being rendered would. This would also lead to the framerate falling for a larger screen size.

I however could be very wrong....
My uneducated understanding:

Texels per second does not measure anything relating to writing texels/pixels. It has everything to do with reading texels from a texture.

Every time the GPU, somewhere in one of its pixel pipelines, has to ask for the color of a texture at a certain location, this adds one to the texel count. Some cards might simply have a very high memory bandwidth/speed, and can look up these values very quickly. This results in a large number of texel lookups per second. Some cards might have very intelligent cache systems, such that even if the memory is slow or has a narrow bus, the cache does a great job of providing texels quickly anyway. This again results in an increased number of texel lookups per second.

When is a high texel/sec rate useful? If you use bilinear or trilinear filtering, you will be grabbing more texels per pixel, and thus assuming the otherwise exact same scene, you'll be needing more texels per second. If you use multiple textures or multiple passes, then assuming the same scene in terms of geometry, you'll again be grabbing more texels from memory per frame, and thus could use a higher texel/sec rate. If you have a high degree of overdraw, and don't care to fix it, again, you'll need more.

Using less detailed textures probably won't help much, as the card will still need to do a lookup for every single texture for every single pixel, or multiple lookups when using some form of filtering. It might help the cache system, though, because the same texel will be requested more often.
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas only, and not for things themselves." - John Locke
i had assumed that the more resolution of the texture, the more texture lookups are required. is this true?
Quote:Original post by sriniatig
i had assumed that the more resolution of the texture, the more texture lookups are required. is this true?

No. A certain number of values is retrieved from a texture (including its mipmap chain) for each fragment, and that number is dependent on the filtering mode, not the texture resolution. Think of it this way: Does it take you longer to read page 23 of a 50 page book, or page 23 of a 5000 page book?
I understood about the number of texture lookups but what i had meant about texture lookups was that more pixel read cycles will be required. So provided the texture resolution will be high, would it take more time to read a high resolution texture than a low res one?
Again, no more reads will be required. If a given blend mode causes you to read 4 different values from a 16x16 texture, it will cause you to read exactly 4 values for any fragment which does this lookup, and it will cause you to read exactly 4 values from a 1024x1024 texture as well. (And, of course, if a triangle takes up 50 fragments on screen, it'll do so regardless of the resolution of the texture on it.) It doesn't use any more reads just because there's more detail. That's actually why mipmaps are used.

This topic is closed to new replies.

Advertisement