Jump to content
  • Advertisement
Sign in to follow this  
Sigvatr

OpenGL OpenGL Performance and Optimization

This topic is 2689 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement

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.
[/quote]

I don't know where you came up with this, but it sounds like BS to me. OpenGL doesn't get 'confused'.


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.
[/quote]

This, on the other hand, is a good idea. Immediate mode is terribly slow compared to using vertex buffers. One thing that can slow down opengl is making lots and lots of opengl calls, which is what immediate mode is all about. If you can render a mesh with 5-10 calls that's a big improvement over per-vertex opengl commands.


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.
[/quote]
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 :)

Share this post


Link to post
Share on other sites
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 ...)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites
Structuring your code better is definitely highly recommended but it's not going to get you anything if you're bottlenecked elsewhere. The first thing you need to do is get away from immediate mode; even just a simple switch to vertex arrays will be of benefit to you here. You also need to examine your code carefully for any potential software fallbacks and cases which could cause your CPU and GPU to need to sync. On modern hardware you can quite easily fall back to software in some places by just using formats that are not natively supported by your hardware. A classic example is glTexSubImage2D; if you're using than anywhere in your code, and if you're using a GL_RGB format, you're probably falling back to software for texture updates. Anything that needs to read back from the GPU will cause a sync so watch out for glReadPixels, occlusion queries, etc.

OpenGL.org has a good Common Mistakes page that you can use a reference for sanity-checking your code; it's explicit purpose is to address bad code that people have picked up from tutorials: "Quite a few websites show the same mistakes and the mistakes presented in their tutorials are copied and pasted by those who want to learn OpenGL" and some of the items discussed on it will probably ring a bell with you.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
I have no knowledge about those stuff, but I also heard/read some times about using BGR instead of RGB for some performance reasons

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
See: http://www.opengl.or...and_pixel_reads

And if you are interested, most GPUs like chunks of 4 bytes. In other words, RGBA or BGRA is prefered. RGB and BGR is considered bizarre since most GPUs, most CPUs and any other kind of chip don't handle 24 bits. This means, the driver converts your RGB or BGR to what the GPU prefers, which typically is BGRA.[/quote]
Also read the section following it on "Image Precision" - http://www.opengl.org/wiki/Common_Mistakes#Image_precision

I can produce a small test app that confirms this 100% - GL_BGRA is up to 6 times faster than GL_RGB on even NVIDIA hardware. Your hardware stores textures internally in BGRA order (more or less no matter what you specify for internalformat) so sending data in any other format will cause a slowdown by requiring it to be converted. Formats like GL_RGB are nothing more than cruddy old crap left over from the days of SGI workstations and 3DFX cards.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!