Trying to get good fill rate…

I went home last night and commented out my entire rendering loop in an attempt to locate any potential fill rate issues (unnecessarily clearing the screen,…). Now I calculated my frame rate at over 1017 frames (in theory).

1017.2… = (800,000,000 pixels/s) / (1024 * 768)

Right?

Anyway with the code in the loop commented out I get like +50m frames a second (to bad the whole game doesn’t run this fast ). Now I only uncomment SwapBuffers and the frame rate drops to 700. Wth, I thought that the buffer swap was a pointer swap (obviously not). Even if its not I still am taking a big hit for a memcpy that (hopefully) is taking place entirely in the card. Is there anything I could be doing wrong? SwapBuffers is the only call in the loop and I’m running the app in windowed mode, so technically I’m not even using the whole 1024x768…

Thanks…

John.

If you’re running in windowed mode you’ll always get a copy rather than pointer swap.

oh… all that concern for nothing.

Thanks!

John.

Humus, that’s not true for workstation graphics boards.

Exactly how is windowed mode different than fullscreen mode?I thought fullscreen is just a fulscreen window wich covers the whole screen.Or is that only in linux/X11 and windows is different?

Well, you’re right that fullscreen is just a window that covers the whole screen. However, in fullscreen the driver can do certain optimizations. In windowed mode it’ll need to copy your smaller backbuffer into the “global” frontbuffer when it does a buffer swap. In fullscreen it can just switch memory pointers between front and back buffer. This holds true at least for all consumer level cards, but as Relic pointed out, workstation card may have special hardware on their RAMDAC to dynamically assign certain screen areas to different framebuffers. This makes a lot of sense for workstation cards which are mainly operating in windowed mode, while normal gaming cards tend to be used in fullscreen mode.

Certain OpenGL implementations will actually always render GL into a “video” overlay, so that swapbuffers is always a pointer swap.

However, it may be that the driver needs to do other kinds of synchronization and housekeeping inside swapbuffers, so I wouldn’t expect swapbuffers to be entirely “free” even if it’s just a pointer swap.