Hi there,

Like many other poor, unfortunate souls, my OpenGL game engine was based off of the skin and bones of well-known tutorials and articles on the web, which resulted in the engine being heavily based on slow techniques such as glBegin/End loops and other immediate mode junk. I have the feeling now that the performance of my engine can be improved significantly due to its lackluster performance at the moment.

I was wondering what techniques I can use to speed up my engine. Right now, the GL code is scattered in and out of the engine's internal logic and systems, so I'm wondering if GL is getting confused or lagging because it is depending on my engine to handle a bunch of stuff for every frame while it is trying to run in and of itself.

I don't know too much about it, but is there a way to encapsulate all of my OpenGL code in a place where the engine internals and logic aren't slowing it down or messing it up? Someone mentioned that a lot of my OpenGL code is running in software mode, which is not good. I think the general idea should be to get as much of it as possible into hardware mode.

I think I most probably should handle things in this fashion:

1) Perform non-OpenGL, engine and game stuff (or have them in a seperate thread entirely).
2) Update an intermediary "buffer" of data that translates non-OpenGL data (ie. model and sprite positions, animations, deformations etc.) into data that OpenGL can execute when it is time to render (using vertex arrays, vertex buffers, etc.)
3) Render all of the OpenGL stuff without having to manipulate any data (as all of the manipulation has been performed prior to the render call).

The jist that I am getting from people is that I need to stop using glBegin/End loops for literally everything and make as much use from vertex arrays and vertex buffers as possible. I've also been advised that display lists are deprecated, so I think I will try and avoid those.

However, as much as I think I should avoid software (non-OpenGL) processing in the middle of the OpenGL rendering process, there are a few things that I think will be unavoidable, such as setting uniforms in shaders and things like that.

Anyway, basically I'm just looking for pointers on how to optimize my rendering. Am I correct about the things I have stated above? I think that to increase the performance of my engine I need to do the following:

1) Keep the non-OpenGL and OpenGL processing as seperate from one another as possible (and probably in different threads at some point).
2) Translate all necessary data into vertex arrays and vertex buffers before the OpenGL rendering process.
3) Perform all the OpenGL rendering at once.

Feedback very much appreciated. I'd also like to know what aspects of OpenGL are handled in software and what are handled in hardware.

Cheers,
- Sig

Your engine probably won't get that much faster if u only modularize everything( divide the rendering from the game logic), but it is highly encouraged, because of all the benefits u get working with it.
Adding new features will become allot more easy and so on.

From a performance perspective you want to talk as less to the GPU as possible, the GPU shouldn't be spending half its time processing commands or data from your engine it should just render things :-)
So storing your geometry data in BufferObjects is of course the first step, because u will only send the data once. The second thing is to somehow order your rendering so as less OpenGL state changes are made as possible(changeing Shader, Textures ...)

First you should bring all your OpenGL code to one central point, it much easier to have all your rendering code together and you'll need it to be together for some optimizations you can do later.
Start using vertex buffers but dont build them every frame, most of your vertex buffers you will only have to fill on load time (just like textures)

If this isn't a big improvement enough for you you can think about culling, no need to make render calls for objects you wont even see.
Finally you can do sorting / batching, since you got all your rendering in a central place now you can do this relatively easy.
About having a rendering thread i'm not sure but if you insist you can look into command buffers.

However, as much as I think I should avoid software (non-OpenGL) processing in the middle of the OpenGL rendering process, there are a few things that I think will be unavoidable, such as setting uniforms in shaders and things like that.

This is wrong. It doesn't matter what you do in between opengl calls. An opengl call just puts a little data in a pushbuffer for the gpu to fetch on its own. This happens totally separate to what's going on in your client side program, and opengl doesn't care if you do other things in between calls. In fact I could imagine this being slightly faster then batching up all of the calls at the end of the frame, as you're giving the GPU more time from when you start handing it work before you're waiting for it to finish to swap the frame. Still you may prefer to put all the opengl code together just for the sake of organization and your sanity
[/quote]


This isn't really true, in fact the OP is more on the ball here.
The first thing is that GPU drivers will buffer up a couple of frames worth of calls before they are dispatched. So you might have to issue quite a few draw calls before the card starts processing what you ask it to. (I believe both AMD and NV buffer at least about 2 frames worth of data before getting under way).

In fact the better way to go about it is to buffer up all your GL/D3D calls until you have a list of what you want to process and then blast through it; the reason for this is because each call transistions from your code to the
driver and back, by batching everything up and doing it in one go you get better cache usage on the CPU which can be a win.

An increasingly common method of dealing with this is to figure out what you want to draw and put it into a sorted list (well, some form of contiguous memory buffer anyway), then when you have all this up front you can do the least amount of work possible to render things as you can batch up state block setting and instanced draw calls to make good use of data and instruction caches.

(This setup also lets you assemble the draw list over multiple threads before using a final thread to kick the draw off which can speed things up vs trying to sort and draw everything on a single thread).

All that said the amount you want to worry about all that depends on just how hard you want/need to push the system. Assembling a draw list across multiple threads for example is an extreme end optimisation as it certainly won't be easy to do and do right/quickly.

occlusion queries have a callback that lets you know when the result is ready
GL_RGB...? can someone verify this? because ive heard the exact opposite

I have no knowledge about those stuff, but I also heard/read some times about using BGR instead of RGB for some performance reasons

I have no knowledge about those stuff, but I also heard/read some times about using BGR instead of RGB for some performance reasons

From what I understand, BGR is used for some image formats such as TGA files. Although I am sure there is more to it than just that.