[gameprogrammer] Re: Optimizing opengl rendering

On Monday 04 April 2005 20.24, Scott Harper wrote:
> Real quick before we get into optimising OGL, just using 2D quads
> for a game, do you even NEED to optimise it?  How bad of a framerate
> hit are you getting?  What's your system like?  How many quads do
> you have to be rendering before you start slowing down?

Well, as an example, my SDL port of XKobo, Kobo Deluxe, supports 
OpenGL rendering through a wrapper that implements the SDL 2D API 
over OpenGL. There are more layers of abstraction in between the game 
logic and the SDL API at that, and I haven't bothered optimizing 
anything on the low levels.

Every sprite is a quad. Large surfaces are tiled - that is, multiple 
quads. Every glyph in the text that scrolls and slides around over 
the map in the intro mode is one or two (due to internal tiling of 
the extremely wide SFont surfaces) quads. Every single "non-space" 
pixel in the radar display is a quad. There is quite a bit of not too 
optimized tiling and clipping logic in between the emulated SDL API 
and OpenGL.

The insane framerates people with fast 3D cards have been getting 
suggest that it's still the accelerator that limits the frame rate; 
not the CPU. Even though there is a considerable amount of code in 
the Kobo Deluxe gfx engine and the glSDL wrapper, it's *nothing* 
compared to what your average 3D game engine has to do before it gets 
around to make OpenGL calls.

So, if your problem actually is that you can't keep the GPU busy, I 
suspect something funny is going on in your code. Unless you have 
some crazy setup (like an old P-II driving a GeForce 6800 card :-), 
you should have to do some rather hefty calculations and/or render 
very small quads to get in trouble.


> I'm mostly just really curious what kind of system and how many 
> textured quads it takes before OpenGL starts to get slower.  For 
> educational purposes. ^_^

Slower than what? *Anything* you do will of course slow down your main 
loop. ;-D

Do you mean "When does an OpenGL application get CPU bound?"

Really, there isn't any specific point where you run into trouble. 
There is a "sweet spot" where the CPU and GPU share the work load 
evenly, to maximize the frame rate on a given system, but the only 
way to hit that on every system is to make the engine *extremely* 
scalable. (That is, very complex.)

In real life, I guess you'd just decide on some sensible CPU/GPU power 
relation and chose your algorithms so that you get some spare CPU 
power for other stuff. Scalability is basically two cathegories of 
user options: Detail level (LOD, model detail, particle effects etc) 
and rendering quality (texture filtering, blending effects, mapping 
effects etc.) The former affects both the CPU and the GPU whereas the 
latter is mostly about GPU bandwidth.

I did some performance tests with glSDL/wrapper and glSDL/backend (the 
"real" backend version; not yet in mainstream SDL releases) by 
setting a fake max texture size much lower than that of the card. 
IIRC, it wasn't until somewhere around 16x16 that I started seeing 
significant slowdown. In fact, there was a sweet spot somewhere below 
256x256 - larger tiles than that would slow things down! This was on 
a 933 MHz P-III with an ATI FireGL 8800 (workstation card based on 
the Radeon 8500 generation), but if I'm not confusing things, the 
same general behavior was observed on nVidia "gamer card" based 
systems as well.


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---


---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: