texture's GL_REPEAT performance

I was fiddling with some textured tiles earlier, and I noticed a significant performance degradation when I increased the “clamp value” on the texture coordinates from 1.0 to a higher value (in my case it was raised to 30). In my test case, I was only drawing 9 large GL_QUADS, and wanted to tile a texture on these large quads so that the texture resolution was more appealing.

When I was clamping the texture coordinates to 1.0, i.e.,:

glTexCoord2f(0.0f, 0.0f);
glTexCoord2f(1.0f, 0.0f);
glTexCoord2f(1.0f, 1.0f);
glTexCoord2f(0.0f, 1.0f);

I was getting ~ 70fps.

When the texture coordinates were clamped at a higher value of 30, i.e.:

glTexCoord2f(0.0f, 0.0f);
glTexCoord2f(30.0f, 0.0f);
glTexCoord2f(30.0f, 30.0f);
glTexCoord2f(0.0f, 30.0f);

I lost about 10 fps, and dropped down to 60fps.

I am pretty surprised that changing the texture coordinates on 9 quads would make such a difference in performance.

I was experimenting with possible work arounds for this problem I am seeing. I subdived each of the 9 quads that have high texture coordinates, leaving me with 36 quads now. The FPS dropped down about another 10 fps, which again seems rather drastic. To get back some fps, I lowered the texture coordinates back down:

glTexCoord2f(0.0f, 0.0f);
glTexCoord2f(15.0f, 0.0f);
glTexCoord2f(15.0f, 15.0f);
glTexCoord2f(0.0f, 15.0f);

This brought me to the same fps that I had if I was just using 1 quad with a higher texture coordinate value. So I decided to scrap that idea.

My second idea, was to double the size of the texture. So instead of using a 64x64 texture, i used a 128x128 texture. Once again, the bigger texture made a huge difference in my fps (lost about 10 fps).

What does this imply? Am I initally thinking that perhaps I am filling up my VRAM (i’m testing on an ATI RADEON 7500M 32MB gfx card)? Also worth mentioning: I am using RGBA tgas. I didn’t think that I was loading that many textures into memory, but I could be mistaken. If this is the problem, is there a way for me to see how much VRAM is available (either through code or with a free utility)?

I also noticed something weird: I tried to crank my texture coordinates up to something ridiculously high: 500.0f. This only dropped my fps down by 10. Whats more bizzare is that using a value of 1550.0f doesn’t seem to make a difference from using a value of 500.0f.

Also, I am having doubts that this is a problem with VRAM. I reduced the size of some of my textures, and it did not seem to make a difference.

Does anyone have a good explanation of this, or have any pointed questions that could lead me to a better understanding of why I am getting these results?

It may have affected fill performance due to cache behavior, especially if you weren’t MIP mapping or had a magnification filter initially.

I don’t think it is a fillrate issue. I lowered the screen resolution and there was no difference in fps.

This is not what he meant.

Every time it draws a pixel it’s got to read a texel (at least 1) from the texture. It doesn’t read the texel from the texture memory directly, it reads it from a cache (small bit of efficient memory next to the ‘processor’). If the texel isn’t in the cache, it has to request the relevant bit of texture memory to be copied into the cache, and then continues drawing. As you can imagine, if you’re repeating the texture many times, it’s pretty much always having to fill the cache for each new pixel it draws, as the new texel is far away in texture memory from the previous texel. This is especially true if you’re not using mipmaps, because the texture you’re using takes up more memory, so the new texel is even less likely to be in the cache.
This is why you’re experiencing a slow down.

Ahh. Thank you all very much for clearing this up with me.

I am using mipmapping, via the following call:

gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGBA, thisTexture->width, thisTexture->height,GL_RGBA, GL_UNSIGNED_BYTE, thisTexture->data);

Am I stuck with this performance hit? Or is there some way around this?

It could still be the cache even if MIP mapping, you may have not been minified as I said earlier and subtle changes in frequency or orientation can impact cache performance slightly.

There are several options you might try, you could change the minification filter, you could change the texture internal format or you could use compressed texture if available.

Each of these may improve performance by reducing the bandwidth used by texture.

P.S. thanks for explaining to him knackered :slight_smile:

Thank you both for all of your help. Although I was building the mipmaps, I guess I wasn’t using them. I needed to use this:

I was misunderstanding the advice I was given.

Thanks again for your patience!

The MAG filter should be GL_LINEAR or GL_NEAREST. Only the MIN filter should use a MIPMAP token.

You may want to try GL_LINEAR_MIPMAP_LINEAR for better quality.