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.

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.

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)

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...

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.

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.