[gameprogrammer] Re: Optimizing opengl rendering
- From: David Olofson <david@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Mon, 4 Apr 2005 21:19:14 +0200
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:
