Hi.
I'm working on my first big project using OpenGL, and I've encountered a problem that's left me stumped.
I wanted to see how many sprites I could handle without going below 60 fps on my computer. It seems like it would be able to handle 10k sprites just fine, but at regular inters (AFAICT, exactly every second regardless of framerate) my framerate drops by as much as 75%. I've narrowed it down to the call to glSwapBuffers() arbitrarily taking longer for no apparent reason. Even if all I do every frame is call my renderer, I still get lag.
I'll post my main rendering function, in the hope that someone can spot something I'm doing that's obviously wrong:
typedef GLuint texture_t;
struct Vertex{
real_t x,y;
};
struct Color{
real_t rgba[4];
};
struct ComplexVertex{
Vertex screen_coordinate;
Color color;
Vertex texture_coordinate;
};
Update: I've determined that the problem doesn't appear to be my code. I observed the exact same performance pattern when I tried running Quake 3 Arena without vsync. Only OpenGL applications have this problem.
Well, now I really don't know what to do. If it's a driver issue, all I can do is hope it gets fixed eventually or try to find an older version that doesn't have this problem.
I'm completely guessing, but it could be because your CPU-side milliseconds-per-frame is too low and your GPU-side milliseconds-per-frame too high.
For example, say you CPU-side loop takes 1ms to complete, but the [font=courier new,courier,monospace]gl*[/font] calls that it made have resulted in 3ms worth of GPU work. These [font=courier new,courier,monospace]gl*[/font] calls push commands into a queue, which is consumed by the GPU. Usually, there is a decent amount of latency in the queue (e.g. 33ms) and this is normal.
However, if every 1ms, you're adding 3ms of work to the queue, then that latency will increase over time -- after 1 second of gameplay, the latency in that queue will have grown to 3 seconds!
If the driver detects that there is too much latency in this queue, then it can choose to stall the CPU completely (by blocking in [font=courier new,courier,monospace]SwapBuffers[/font]) until the GPU has caught up.
If this is the case, you can fix the problem by -
* not sending more frames worth of commands to the GPU than necessary. e.g. a 60Hz monitor can only display 60FPS, so running Q3 at 600FPS is useless.
* capping your CPU-side framerate yourself, so that the driver doesn't have to.
* profiling how much time the GPU is taking to actually process your [font=courier new,courier,monospace]gl[/font] commands (N.B. you can't do this by timing [font=courier new,courier,monospace]gl[/font] API calls, you need to insert timing events or use a profiling tool) and ensure that your GPU milliseconds-per-frame is roughly equal to your CPU milliseconds-per-frame.
Suppose I inserted an empty loop in the middle of my game loop such that I can be sure that the time spent outside of rendering amounts to over 95% of the run time of the program and the framerate never exceeds 40 fps. What does it mean if the framerate still drops quite visibly?
I can also monitor GPU usage from Process Explorer and it practically idles to run my program.
EDIT: If the answer to the above question is "it doesn't mean anything", is there any way I can improve my code? My target is being able to draw as many sprites as possible as efficiently as possible, considering that they'll be moving constantly and independently, and that sprites may be created or destroyed at any time.
"My target is being able to draw as many sprites as possible as efficiently as possible, considering that they'll be moving constantly and independently, and that sprites may be created or destroyed at any time."
Surely you just need it to draw enough for your game? Otherwise, you're just getting side-tracked optimising something you don't need optimising.
I figured it out. Remember I said the lag spikes happened once every second regardless of framerate? Remember also I said I could monitor GPU usage from Process Explorer? Turns out, PE's probing of the GPU was adding a huge amount of delay (up to 15 ms) to a few frames once every second.
I still think it's strange that only OpenGL applications behave like this, though.
Hodgman: What you said about sending work to the GPU faster than it can handle it, how could I determine if this was happening? Not that I think it's happening now, but I would like to be prepared if the need arose. Could you recommend a profiler?
I can also monitor GPU usage from Process Explorer and it practically idles to run my program
"Resource usage" stats from apps like these are a nice hint, but generally shouldn't be trusted as a source of profiling data.
Turns out, PE's probing of the GPU was adding a huge amount of delay (up to 15 ms) to a few frames once every second.[/quote]Hah! That's interesting... So it doesn't occur if you ensure PE isn't running?
Hodgman: What you said about sending work to the GPU faster than it can handle it, how could I determine if this was happening?
[/quote]I'm a bit out of the loop with the GL side of things. I used gDEBugger a while ago, but can't remember how good it's profiling tools were.
To build your own GPU-side frame-timer, you basically want to create a ring-buffer of "event"/"query" objects and submit one at the start of each frame
-- e.g. an array of 3 or more queries, and increment a counter (wrapping around to 0 at the top of the array) that selects which one you'll be submitting that frame.
You need more than one query because of the latency between the CPU and GPU.
Before you reuse a event/query, you can read it's actual time value, which hopefully has actually been written by the time your array/ring wraps around.
I've not done this with OpenGL, but I believe you can use the ARB_timer_query extension.
Most of the game engines I've used have had some kind of on-screen display of this timer info , e.g. two bars at the bottom of the screen, one for CPU time in ms and one for GPU time in ms, with lines/markings on the bars showing 16.6 and 33.3ms (60FPS and 30FPS, respectively).
Hah! That's interesting... So it doesn't occur if you ensure PE isn't running?
Yep. If I shut it off I can get a stable framerate with up to 15k sprites on the screen, which is well above my target. If I couldn't handle such a measly number without stuttering, I was going going to be in trouble once I turned scripting and audio back on and added the 3D bits.
To build your own GPU-side frame-timer, you basically want to create a ring-buffer of "event"/"query" objects and submit one at the start of each frame
-- e.g. an array of 3 or more queries, and increment a counter (wrapping around to 0 at the top of the array) that selects which one you'll be submitting that frame.
You need more than one query because of the latency between the CPU and GPU.
Before you reuse a event/query, you can read it's actual time value, which hopefully has actually been written by the time your array/ring wraps around.
I've not done this with OpenGL, but I believe you can use the ARB_timer_query extension.
Most of the game engines I've used have had some kind of on-screen display of this timer info , e.g. two bars at the bottom of the screen, one for CPU time in ms and one for GPU time in ms, with lines/markings on the bars showing 16.6 and 33.3ms (60FPS and 30FPS, respectively).
So it doesn't occur if you ensure PE isn't running?
