Jump to content
  • Advertisement
Sign in to follow this  
Heelp

OpenGL Which per-frame operations are expensive in terms of performance in OpenGL?

This topic is 821 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

Ok guys, I already made the camera and hero movement and I loaded one small map consisting of 100 cubes for my mmorpg. I made some ugly models using blender, and I made a function that reads the vertices from .obj file and stores everything in GLfloat array. The next very important thing I need to know is: What kinds of operations should I try to keep to a minimum in my game?
What I gathered from previous posts is:

 

1. Don't make separate VAO and VBOs for every object, because binding and redefining a thousand VBOs every frame takes time.

2. Don't make too much draw calls because that takes time, too.

3. Calculate projection*view*model matrix outside the vertex shader, so you don't calculate the same stuff over and over.

4. Use spheres for collision whenever you can, because it's the simplest possible bounding object.

 

If anything more comes to mind, write it here, please, even if it's not so beginner-friendly, because I can return to this post at some point in the future.

 

And one more thing: I have a question about that 1st principle I just mentioned. Now that I have 7 or 8 models, what I need is a good, logical, performance-wise way of storing them in memory and drawing them on screen. How should I know when is the right time to make another VAO or VBO. Basically I know that VAO is a list of attributes for a number of objects, and it consists of several VBOs, and one VBO can contain vertex coordinates or textures or normals or stuff like that. So, for example, if I have 7-8 models with their own vertex coordinates, should I keep all their vertex coordinates in only one VBO or should I do something else?

Edited by Heelp

Share this post


Link to post
Share on other sites
Advertisement

You are asking a problem that may not be necessary for many years to come for you. A lot of people ask this and I tell everyone, optimize when you need to. Hardware is extremely fast nowadays that this shouldn't be a concern. Focus on your game if that is what you are building. If you just want to build the best tech in the world, then that is a different story.

Share this post


Link to post
Share on other sites

This kind of thing is actually micro-optimizing with the kind of workload you're doing.

 

The worst operations for performance are and always will be: (1) reading anything back from the GPU, and (2) updating a resource that's in use.  Avoid those, and so long as the rest of your code isn't fighting the API you'll do OK.

Share this post


Link to post
Share on other sites

I'm directx not opengl but my understanding in regards to playing nice with the API they are similar.

 

1. Don't draw what you don't need to.  So frustum and if possible occlusion culling.

2. draw front to back to take advantage of hi-z and early-z.

3. sort by state to reduce state changes between draw calls and use texture atlus's to furture reduce state changes.

4. I agree with your 1,2, and 3 except I would say only make as draw calls as you need to and minimize draw calls using various techniques like instancing.

5. mhagain advice is good as well.

6. figure out the best way to upload uniforms to the gpu. (I remember a couple of threads in this forum where there were performance implications)

Share this post


Link to post
Share on other sites

1. Don't make separate VAO and VBOs for every object, because binding and redefining a thousand VBOs every frame takes time.
2. Don't make too much draw calls because that takes time, too.
3. Calculate projection*view*model matrix outside the vertex shader, so you don't calculate the same stuff over and over.

1. Yes, if you've got different VBO's per object, you'll have to make extra GL function calls to rebind VBO's inbetween rendering each object. Whether or not this is a problem depends on your game. If you're trying to draw 10's of thousands of unique objects, it's probably an issue. If you're trying to draw one thousand, not as much.

2. Basically, any GL function takes up CPU time. If you design your renderer so that you'll make the least GL calls, then you'll save CPU time. However, in order to do this, sometimes you have to do things that are inefficient for the GPU... Depending on your game, it may be more important to optimize for the CPU or optimize for the GPU.

3. As above, if your game has spare CPU time and is over budget on the GPU, then this could be a good idea. However, if the opposite is true (spare GPU time, over CPU budget), then it may be harmful :P

Also, if you calculate projection*view*model on the CPU, then you need to repeatedly set a uniform value for every single object in the scene. On the other hand, if you put projection*view in one UBO and model in (many) others, then you only need to set projection*view once per frame instead of once per object. If your scene is full of static objects (so model doesn't need to be set every frame), this could be a significant reduction in GL calls...

Share this post


Link to post
Share on other sites

1. Yes, if you've got different VBO's per object, you'll have to make extra GL function calls to rebind VBO's inbetween rendering each object. Whether or not this is a problem depends on your game. If you're trying to draw 10's of thousands of unique objects, it's probably an issue. If you're trying to draw one thousand, not as much.
2. Basically, any GL function takes up CPU time. If you design your renderer so that you'll make the least GL calls, then you'll save CPU time. However, in order to do this, sometimes you have to do things that are inefficient for the GPU... Depending on your game, it may be more important to optimize for the CPU or optimize for the GPU.
3. As above, if your game has spare CPU time and is over budget on the GPU, then this could be a good idea. However, if the opposite is true (spare GPU time, over CPU budget), then it may be harmful :P
Also, if you calculate projection*view*model on the CPU, then you need to repeatedly set a uniform value for every single object in the scene. On the other hand, if you put projection*view in one UBO and model in (many) others, then you only need to set projection*view once per frame instead of once per object. If your scene is full of static objects (so model doesn't need to be set every frame), this could be a significant reduction in GL calls...


These are great examples because they also illustrate some other factors to be aware (and beware) of.

 

The main thing that jumps out here is performance vs code complexity vs flexibility.  The example of putting all objects into a single VBO is a great use case for this.  On the one hand you get to reduce VBO binds, but on the other hand your model loading code becomes more complex because you've now got to record offsets for each object (as well as handle the case where a VBO you allocate up-front may not be large enough).  Then you lose the flexibility to load and unload models on the fly.

 

Depending on your program any or all of these may be a deal-breaker.  So don't let the quest for the absolute theoretical highest performance overrule other goals.

 

The example of matrices is another great one, this time illustrating how an optimization in one place can lead to loss of performance in another.  That's often the case with optimizations: you're making a trade-off and hoping that you come out with a net positive.  In this case setting projection * view one-time-only certainly looks attractive, but you end up trading that off against having to make an extra matrix multiplication per-vertex.  That's one of the reasons why we always say "benchmark", because unless you have measurements you'll never know if the work you did to optimize one area didn't come at a greater cost elsewhere.

Share this post


Link to post
Share on other sites
Also, if you calculate 

 

projection*view*model on the CPU, then you need to repeatedly set a uniform value for every single object in the scene. On the other hand, if you put projection*viewin one UBO and model in (many) others, then you only need to set projection*view once per frame instead of once per object. If your scene is full of static objects (so model doesn't need to be set every frame), this could be a significant reduction in GL calls...

 

 

Question. Im a stupid person, maybe I don't understand something, but follow my logic here. If I have 2 million vertices, then the vertex shader runs 2 million times. Why would I want to calculate projection*view 2 million times per frame, when I can do it only once per frame in the cpu? What tradeoff??? :blink: 

Edited by Heelp

Share this post


Link to post
Share on other sites

Question. Im a stupid person, maybe I don't understand something, but follow my logic here. If I have 2 million vertices, then the vertex shader runs 2 million times. Why would I want to calculate projection*view 2 million times per frame, when I can do it only once per frame in the cpu? What tradeoff??? :blink: 

 

 

 

Also, if you calculate projection*view*model on the CPU, then you need to repeatedly set a uniform value for every single object in the scene. On the other hand, if you put projection*view in one UBO and model in (many) others, then you only need to set projection*view once per frame instead of once per object. If your scene is full of static objects (so model doesn't need to be set every frame), this could be a significant reduction in GL calls...

 

He explains it with the above.

Also GPU's are ALU heavy and they can tear through calculations.

Share this post


Link to post
Share on other sites

Why do I need to repeatedly set a uniform value, uniform value is only set up once, and it works for all the vertices, that's why I had declared it to be uniform in the first place.

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!