Texturing == Slow Down
Author
Hi Everybody...
I'm having a really strange issue. I've been reworking my engine to use OGL, and I thought I was doing good until I added texturing. W/O texturing, I'm pulling nearly 300 fps, with texturing, it drops to about 8 :( What's worse is that it only happens on my laptop which uses a radeon 7500, on my desktop I have a radeon 9500 pro, and I see a freame drop, but only by maybe 20 - 50 frames. My setup is that I'm using vertex buffer objects to hold the data for a terrain. Is it possible that the laptop mem is so small that it can't hold the verts and a texture? I find this strange because I can increase the size of the terrain from 64 x 64 to 256 x 2256, and the program still runs. Hopefully someone else has gon through this before and can shed some light on it. Thanx for the help.
Author
Ok, small update, I switched from using VBO's to storing my vert arrays in sys memory. While the whole thing runs slower, I now get about 90fps. Still, I would like to know why the drop with texturing and VBO's on.
Author
Nope, my problem shouldn't have anything to do with any other call as the call to bind textures and set texcoords gets called regardles of whether or not I turn on texturing. The entire difference between 300fps and 6.6fps seems to be in glEnable( GL_TEXTURE_2D ) if I am using VBO's. Without the VBO's it's not so dramatic, but, like I said, I'd rather use them.
The texture in question is 1024 x 1024
The texture in question is 1024 x 1024
Author
Hmm... don't think that's it, I reduced it to 512 x 512 which is what the NeHe VBO tutorial uses as both the heightmap and the texture, which runs at 120 fps on my laptop and is 4 times more vertex data. I thought it might have something to do with the use og glDrawArrays in the NeHe tut compared to my use of glDrawElements, but it seems like index buffers would be more efficient. Changing to glDrawArrays sped the app to about 25-30 fps, but that's still way lower than the 120 of the NeHe app, I may have to dig more to find just what the problem is. This is annoying. ... Could using triangle strips make that much of a idfference?
Author
At this point I really don't expect anyone to know the answer to my problem, so I'm really just logging my process now incase someone else on the net needs the info. Anyhoo, I find that the issue may not be a memory one as I can turn texturing on as long as I turn it off right before the glDrawElememnts call. Also, strangely enough, when I switch to wireframe, it goes down to 6.6 fps, which is understandable, but turning it back tofill mode does no fix the framerate.
Obviously using a texture vs. not using a texture will ALWAYS be slower to fill, due to the memory bandwidth overhead of the GPU reading the textures.
But lower res textures can of course make some difference (I haven't done any benchmarks, so don't ask).
Mip-mapping uses more vram, but it's not clear what its performance implications are.
If your textures are so numerous and/or big that many of them are being swapped in/out of vram each frame, that will cause a HUGE performance decrease. Avoid it at all costs.
If you *reduced* your texture to 512x512, that's still pretty huge. Sounds too big if you plan on having several different ones. It's going to make rendering slower.
Mark
But lower res textures can of course make some difference (I haven't done any benchmarks, so don't ask).
Mip-mapping uses more vram, but it's not clear what its performance implications are.
If your textures are so numerous and/or big that many of them are being swapped in/out of vram each frame, that will cause a HUGE performance decrease. Avoid it at all costs.
If you *reduced* your texture to 512x512, that's still pretty huge. Sounds too big if you plan on having several different ones. It's going to make rendering slower.
Mark
Quote:Could using triangle strips make that much of a idfference?
If your terrain data has dimensions W x H, and you are using GL_TRIANGLES, you will end up sending (W - 1) x (H - 1) x 3 vertices to the driver.
If you arrange your vertices properly and use GL_TRIANGLE_STRIP, you end up sending roughly (H x W) x 2 vertices to the driver.
Same result; less work. Will it solve your problem? Who knows, but its worth a shot. Your video card might be memory bandwith limited.
- carb
Quote:
Mip-mapping uses more vram, but it's not clear what its performance implications are.
It's very clear what its performance implications are. It helps to increase cache coherency, and can increase your performance by quite a lot. If you can afford it, always use mipmapping. Especially on large textures (1024, 2048, etc..) that are tiled a lot.
Y.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
