Fillrate Question

Hi there,

I’m quite new to OpenGL and 3D Programming and can’t explain what I lately discovered:

I set a 512x512 Texture and render about 10k triangles using this texture. Rendering is done with vertex arrays and multiple calls to flDrawElements. Each of that calls renders 8 triangles.

It’ seems that fillrate on my GeForce 2 is the limeting factor. When I use a smaller texture (64*64) frame rates double from 50 fps to 100 fps. How can this be explained ?

I thought it doesn’t matter what size a texture has as long as it fits into texture memory ? Is cache usage with a smaller texture so much better ?

Please give me a hint :slight_smile:

Yes.

Just a guess. Since OpenGL has to map texels to pixels, mapping more texels should take more time. Hence larger textures should be slower. Of course I’m no expert and could be wrong.

I thought things would function like this: OpenGL tries to find the right color for every pixel on screen by looking up the nearest texels an doing so filtering afterwards. It shouldn’t matter wether 4 texels (in case of bilinear filtering) are looked up in a smaller texture or in a bigger one.

[This message has been edited by muhkuh (edited 04-25-2002).]

If you specify GL_LINEAR, OpenGL must pick up all texels that map to the pixel. In the case of a larger texture you might get 2 - 4 times more texels mapping to 1 pixel, hence more work. Thus larger textures should be slower.

If you specify GL_NEAREST it should pick up only the texel closest to the the pixel. If it grabs the first texel it finds then I guess it should not matter. If it searches all texels that map to the pixels centre or something then its going to be slower for larger textures as it will have to search more texels per pixel. Check the specs to see which it is.

it always takes more time to find a pixel in a big texture, thats why we have mipmaps, then the gfxchip can select the right size of the image before looking up the pixels.

Are you sure about this ? I thought GL_LINEAR would always take 4 texels and compute a weighted avarage, no matter how big the texture is.

Edit:
Why should it take longer to find a texel in a larger texture ? It’s just the same math going on. IMHO the reason for mip mapping is image quality.

Edit2: from the MSDN
GL_LINEAR
Returns the weighted average of the four texture elements that are closest to the center of the pixel being textured.

[This message has been edited by muhkuh (edited 04-25-2002).]

You are correct. In that case I’m at a loss. It may have something to do with whether the texture is resident in video memory or being pushed across the bus, but I know nothing of those matters.

strange…,AFAIK things might be a little slower w/ a larger texture but certainly not 50fps slower.
BTW:
mipmapping has nothing to do w/ reducing texel lookup time(at least not that I know of) or anything.It’s used to get rid of the aliasing caused by resampling the texture images.

Actually mip mapping will improve performance with minified textures because the implementation won’t have to sample as many pixels. If the texture is minified lots of texels can contribute to a single pixel and thus lots of samples have to be made which slows things down. With mip maps the texels/pixel ratio is more constant and performance is increased.

Finding the 4 texels to compute a bilinear filtered pixel seems like a constant operation to me. Why should this be faster with smaller textures ?? The only thing that could speed up lookups in smaller textures would be a cache of some kind because with a large texture the propability of a chache miss is greater.

Anyway, I didn’t even use mip mapping. I just wanted to know, why reandering x triangles each with a 512x512 texture is so much slower than rendering the same triangles with a 64x64 texture. Every triangle uses the same texture coordinates.

If it only fetches 4 pixel for the filtering then i have no explanation, but the result is still clear, it’s a faster to render 1 6464 than a 10241024 ( those was the formats i tested, and i know they both where in the gfxMem at the test)

if it is a HUGE difference between the 64 and the 512 texture, then check - does they reside in the gfx mem, and/or do you upload them every frame yourself. thats the only things i can think of…

As I said I’m new to OpenGL. I do glGenTextures(…);
glBindTexture(…);
glTexImage2D(…);
once as I read in many tutorials.

Every fram I do a

glBindTexture(…);

I just have 1 texture so the 512x512 texture will feel pretty lonely in the texture ram of my 64MB Geforce 2.

Please drop a line if this is the correct way to do it. If it is I must have some other bug in my code.

Smaller textures are faster because the GPU has a on-chip texel cache.

So the smaller the texture the better the chance of a cache hit which is much faster than grabing the texel from the video memory.

LG

Depending on the screen size and filtering method is it possible that they are using different methods. If the polygon covers more than 64 but less than 512 pixels and you are using the more expensive mipmap filtering will the 512 texture be using several mipmap levels but not the smaller. Perhaps can that explain some of the difference.

Well, as I wrote I’m not using any mip mapping. The texture cache explaination seems the only one possible.

With a smaller texture, a texel will cover more pixels during rasterization, and will be used to texturize more sequential pixels than a texel from a larger texture. As LG said, since all chips worth mention has on-chip texture cache, the texel can be fetched from the cache instead of from the video memory. The cache is much faster than the video memory, and you don’t waste any memory bandwidth, which then can be used more effective by Z-test, framebuffer updates, and so on.

Mipmapping helps texture chaching, since for distant textures, the chip has to sample the texture with large steps (many texels between two samples), and if you can reduce the size of the texture levels, the chip can lower the amount of cache misses (on a cache miss, it has to fetch a new texel from video memory).

[This message has been edited by Bob (edited 04-27-2002).]

Originally posted by muhkuh:
Well, as I wrote I’m not using any mip mapping.
Do so!
True bilinear minification ala MSDN (only four texels fetched) would produce lots of artifacts anyway. It wouldn’t puzzle me at all if MSDN is inaccurate here.

Of course I’ll be using GL_LINEAR_MIPMAP_LINEAR with mip mapping later on. I was just doing a performance test to find out how many textured triangles I can render.