4

I have heard that fewer drawing calls = faster The implied lesson is to pack as much vertex data into as few arrays as possible to minimize the number of drawing calls.

I was thinking of writing a rendering framework on top of OpenGL to pack all vertex data into a small number of arrays and draw the entire scene in only a few drawing calls.

My question is if this actually ends up faster if doing ALOT of drawing in one call (for instance to glDrawElements)?

I have also heard that if you try to draw too large of a vertex array with one call it will overflow the cache and not really end up being faster.

Dan D.
  • 73,243
  • 15
  • 104
  • 123
Prime
  • 4,081
  • 9
  • 47
  • 64
  • I'm currently implementing a similar pipeline for KRI engine. I would like to have a clear answer to your question myself. – kvark Jul 24 '11 at 00:48

1 Answers1

4

This article will be of great use to you: http://www.nvidia.de/docs/IO/8230/BatchBatchBatch.pdf

IMHO, you're better of optimizing for state changes. I.e. minimize the amount of times you have to switch shaders or textures, etc. Those are the 'real' costly operations.

However regarding your question. Rendering an amount of vertices from a big vertex buffer is (in my experience) always faster than rendering from multiple smaller ones.

I'm not sure about the "overflowing the cache" thing. As far as I know the vertex fetch unit fetches vertices directly from GPU memory (well, there is a vertex cache but it only stores on the order of 16 vertices). The only overflow you could have is running out of VRAM, at which point you have bigger problems.

The only other problem with big vertex buffers is that the driver will have troubles moving them around in memory. This isn't a problem if your vertex buffers are static, but you may see some poorer performance when changing the data "on the fly".

Hannesh
  • 7,256
  • 7
  • 46
  • 80