tags:

views:

99

answers:

3

My application is rendering about 100 display lists / second. While I do expect this to be intensive for the gpu, I don't see why it brings my cpu up to 80 - 90 %. Arn't display lists stored in the graphics card and not in system memory? What would I have to do to reduce this crazy cpu usage? My objects never change so that's why im using DL's instead of VBO's. But really my main concern is cpu usage and how I could reduce it. I'm rendering ~60 (or trying to) frames per second.

Thanks

+1  A: 

If you are referring to these, then I suspect the bottleneck is going to be CPU related. All the decoding of such files is done on the CPU. Sure, each individual command might result in several commands to your graphics card, which will execute quickly, but the CPU is stuck doing decoding duty.

Billy ONeal
I'm refering to GlCallList()
Milo
@user: If that's the case, then the CPU/GPU bounding of the function is graphics vendor specific. Microsoft's default drivers do not provide hardware acceleration of OpenGL. I suspect your graphics adapter does not provide such acceleration -- most consumer graphics card vendors neglect OpenGL because games don't often use it. (They use Direct3D instead)
Billy ONeal
I have an Nvidia 9600 GT, it supports OpenGL 3.0, I promise you that it is indeed hardware accelerated
Milo
@user146780: Then to find the CPU hog you're going to need to profile.
Billy ONeal
A: 

You probably have VSYNC disabled. In which case your CPU will generate as many frames per second as possible. Of course most of them will be wasted because your monitor can't update 100s of times per second.

Enable VSYNC and check your CPU usage (and frame rate) again.

Ben Voigt
Tried it, had no effect :-(
Milo
A: 

While display lists are compiled on the GPU, it does not mean there isn't some work required on the cpu (if not directly in your code then possibly in the driver) to actually specify the display list to call on the gpu.

If you want to find out where the cpu time is being spent, grab a profiler and fire up a call graph sampling test. You'll find out in no time where the cpu time is being spent.