Sign in to follow this  

Texturing == Slow Down

This topic is 4780 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 4780 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this