🔒 Locked

Mipmap performance question

Started by iradel Sep 15, 2005 at 9:39 AM 3 replies 1.7k views

Original Post

Sep 15, 2005 at 9:39 AM

I am testing a program with little in the way of geometry or game logic, but it uses Cg shaders to do bump-mapping, lighting, and vertex displacement. I am testing on two machines: Pentium 4 3.2Ghz HT, 1Gb RAM, XP Pro GeForce 6600 GT/AGP/SSE2 (v.2.0.0) Vertex profile: vp40 (7001) Fragment profile: fp40 (6151) Max Anisotropic Level: 16.000000 and Pentium 4 3.0Ghz, 1Gb RAM, XP Pro Quadro FX 500/FX 600/AGP/SSE2 (v.1.5.2) Vertex profile: vp30 (6148) Fragment profile: fp30 (6149) Max Anisotropic Level: 8.000000 The geometry is basically one big, inside-facing cube, where the walls and ceiling are bump-mapped and the floor has a "wave" effect. There is a single light which moves around inside the cube. On the first machine, I get a steady 60fps nomatter which way I pan/rotate/strafe around/inside the cube. On the second machine, if I start out my camera far away from the cube, I get 60fps. As I move in closer to the cube, there seems to be a sharp boundary where the framerate drops to 30. As I move in closer, there is another sharp boundary where the framerate drops to 15. I tried turning the anisotropic texture filtering off, but that had no effect. I am guessing that the sharp framerate boundaries are caused by mipmap levels. As I get closer to the object, a larger texture is used, and that drops my framerate. Is this a valid assumption, and if so, what does that mean? Is my program fill-rate bound (not 100% sure what that means)? Are the textures too big? Thank you.

Fiddler

Sep 15, 2005 at 10:07 AM

Without knowing anything more about your program, the fact that fps drop when you get closer to a textured surface indicates that fillrate limitations. To see if you trully are fillrate limited - which probably is the case - try running the program in a lower resolution. If fps goes up then (probably) this is the problem.

The sharp drop, however, happens due to vsyncing. Vsyncing means that the screen contents are only updated when the monitor's electron beam turns off (before returning to its starting position), which prevents 'tearing' artifacts from appearing (ie. when updating the screen contents during a beam scan, a portion of the screen will contain old data while the rest will display the new data). However, if the PC cannot process the data fast enough, the gfx card will wait until the next beam scan begins before updating (ie. if you have a monitor refresh rate of 60 with vsync, but your PC can only draw 59fps then vsyncing will cause the fps to drop to 30 - without vsyncing it would be 59 but with artifacts). I hope you see what I mean.

All in all, if you can live with tearing artifacts turn off vsync to get rid of the large fps drops. You can do this either through the card's properties (remember to be admin before trying to change them!), or by using the EDIT: WGL_EXT_swap_control or GLX_SGI_swap_control extensions Kalidor mentions ;)

[Edited by - Fiddler on September 15, 2005 10:07:26 AM]

Kalidor

Sep 15, 2005 at 10:14 AM

Quote:
Original post by iradel
On the second machine, if I start out my camera far away from the cube, I get 60fps. As I move in closer to the cube, there seems to be a sharp boundary where the framerate drops to 30. As I move in closer, there is another sharp boundary where the framerate drops to 15.

That is most likely because of vsync. Without vsync turned off, your framerate will drop "smoothly" as opposed to being halved. This is because of the way vsync works. It waits for the next vertical refresh of the screen to swap the buffers, but if you just miss it (ie: if your framerate would drop even one frame/second below your monitor's refresh rate) then it has to wait until the next one, effectively cutting your framerate in half.

It's probably a good idea to benchmark your programs with vsync turned off. This can be turned off inside your video card's driver settings or with the WGL_EXT_swap_control extension on Windows. I'm assuming for Linux the equivalent (or almost equivalent) would be GLX_SGI_swap_control.

EDIT: Too slow [sad]

FReY

Sep 15, 2005 at 10:29 AM

The other guys are right, it does sound like you're fillrate bound.

Fillrate bound situations occur when your vertex-processor and CPU finish alot quicker than the pixel operations. Pixel operations are things like texture fetches in the pixel shader, filtering, blending and super-sampling. Random (or scattered) texture indirections in the pixel shader can cause texture page thrashing on the GPU (ie. causing texture page to be refilled for every indirection) which obviously defeats the point of the texture cache.

Like the other guys say, mipmapping can have an effect on fillrate, but so can things like pixel shader complexity. It will however be the 'vsyncd' frames that are causing the sharp boundaries.

You could change to BILINEAR filtering (filtering with no mip maps) and use a small texture (ie. something like a 4x4 or 8x8 texture) to determine whether it's the mipmapping/texture fetches.

Something that will be a performance win is to disable blending when you draw fully opaque objects. This will disable read-backs from the framebuffer in order to the blend before write backs - making it faster in these situations.

BTW: Because your program is vsynced, it will have dropped from 60fps > 30fps > 20fps > 15 fps > 12fps > 10fps. (general formala: 60/(1+ num frames dropped))
So yes, test without Vsync enabled.

iradel

Author

iradel

Sep 15, 2005 at 2:56 PM

Thank you for the suggestions.

I did try turning off vsync on the machine with the better video card, and my framerate shot up from 60 to about 120 on a debug build, and 240-260 on a release build.

I will try turning off vsync on the problem machine later today. Hopefully it will help.

Topic Locked

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