I have 100% CPU usage even when I lock the framerate to the vsync. Normally my app runs at ~170FPS, but now it’s locked @ 60 and CPU utilisation is still knocking the roof off! Is the driver polling or something? I have some threads but they are waiting most of the time…
This is on a GF6600 with 77.72 drivers. Does anyone see similar behaviour, or is this something on my side?
Do you use glFlush or glFinish ? try to remove them, just keep SwapBuffers.
I only have SwapBuffers, but I believe it does a glFlush internally…
Ok, I’ve just swapped my main app component to a simple test, and it runs fine without killing the CPU, so it must be something silly on my part…
Sounds like you might have a background thread.
However, I have quite unpleasant memories of vsync in the past. Drivers used to busy-wait for it. I don’t know if they still do, but it could be worth looking out for.
To reduce useless CPU-load, an approach I’ve used is to render a few frames to “warm” everything (caches, textures and so on), then time rendering of ‘n’ frames at two points:
- After last drawing command, and after calling glFlush.
- After glFinish (also only for timing).
After filtering those timings, I have reasonable timings for how long it takes for me to draw the frame (sending commands to the server), and how long the server needs to complete.
Armed with that information, one can f.ex. pre-calculate some stuff for the next frame, or simply sleep for a while, while the GPU does its stuff, before swapping.
Just an idea.
[EDIT: Obviously one should glFlush before doing other stuff, incl. sleeping, even if not timing]
I figured it out, the drivers are fine. The problem was in my font rendering code. I had multiple text windows on the screen, and they shared the same font renderer, thus sharing the same vertex buffer. Even though I double-buffer the VBs, with many windows it’s still not enough, so I stalled on glMap() a lot… well, yeah, so glMap() seems to be a busy wait, but if you have to wait on Map then there is something wrong anyway… I just have to be more clever about sharing VBs between instances (or I could just give each it’s own).
Originally posted by andras:
I figured it out, the drivers are fine. The problem was in my font rendering code. I had multiple text windows on the screen, and they shared the same font renderer, thus sharing the same vertex buffer. Even though I double-buffer the VBs, with many windows it’s still not enough, so I stalled on glMap() a lot… well, yeah, so glMap() seems to be a busy wait, but if you have to wait on Map then there is something wrong anyway… I just have to be more clever about sharing VBs between instances (or I could just give each it’s own).
That’s why it’s recommended NOT to map but to BufferData/BufferSubData instead, which don’t force sync between GPU and CPU.
That’s interesting. How does it not force a sync?
I mean, as soon as the call returns, I’m free to overwrite and/or free my original copy of the data. Does the driver use an additional copy if it’s not ready to overwrite the old buffer contents?
Originally posted by Overmind:
[b]That’s interesting. How does it not force a sync?
I mean, as soon as the call returns, I’m free to overwrite and/or free my original copy of the data. Does the driver use an additional copy if it’s not ready to overwrite the old buffer contents?[/b]
AFAIK, calling BufferData/SubData on a buffer being drawn will make the driver copy your data. What it will do next is up to it, either it copies the data sent to the existing memory-area or set the new memory-area as the buffer (basically changing a pointer).
Updating a buffer that isn’t being drawn should be immediate.
Not sure what’s gonna happen if the buffer is queued for rendering, I assume it would be the same as if it’s being drawn…
BTW, I think we are going off topic somehow.