🔒 Locked

Texturing == Slow Down

Started by INVERSED Nov 14, 2004 at 10:39 PM 10 replies 1.3k views

Original Post

Nov 14, 2004 at 10:39 PM

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.

INVERSED

Nov 15, 2004 at 1:27 AM

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.

Sneftel

Nov 15, 2004 at 1:37 AM

You're not calling glTexImage2D every frame, are you?

EDIT: also, what size is the texture?

INVERSED

Nov 15, 2004 at 5:34 AM

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

Shannon Barber

Nov 15, 2004 at 9:12 AM

That's pretty big, it may exceed the hardware capabilities of the 7500.

INVERSED

Nov 15, 2004 at 1:41 PM

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?

INVERSED

Nov 15, 2004 at 3:36 PM

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.

markr

Nov 15, 2004 at 5:21 PM

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

carb

Nov 15, 2004 at 5:31 PM

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

Ysaneya

Nov 15, 2004 at 5:36 PM

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.

zedzeek

Nov 15, 2004 at 6:35 PM

always enable mipmaps (better performance and usually better visuals), really the only time u dont wanna use them is in say a HUD where the distance doesnt change.
the nvidia drivers even have an option in the display panel called force mipmaps!

INVERSED

Nov 16, 2004 at 1:49 AM

I just want to clarify that it is most deffinitely not the size of the texture causing the slow down. In fact, if you bind 0 as the current texture, it still has a problem. It is probably an issue with a state or something. As simply enabling texturing while the call to glDrawElements is enough to set it off.

As I play with it some more, I find that if I call glDrawElements with only 3 indices I get 200 fps, but if I tell it 6 indices, it drops to 175 fps, and at 30 it drops to 46. Maybe this strange behavior comes because I'm storing my undices in sys mem and my verts in vid mem. Still strange that that's slower than storing everything in sys mem, or that it only happens when texturing is enabled.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.