What Is the Cost of 1 Million Vertices?

Hint: it might not be what you think!  Vertex count isn’t usually the limiting factor on frame-rate (usually the problem is fill-rate, that is, how many pixels on screen get fiddled with, or CPU time spent talking to the GPU about changing attributes and shaders).  But because vertex count isn’t usually the problem, it’s an area where an author might be tended to “go a little nuts”.  It’s fairly easy to add more vertices in a high-powered 3-d modeling program, and they seem free at first.  But eventually, they do have a cost.

Vertex costs are divided into two broad categories based on where your mesh lives.  Your mesh might live in VRAM (in which case the GPU draws the mesh by reading it from VRAM), or it might live in main memory (in which case the GPU draws the mesh by fetching it from main memory over the PCIe bus).  Fortunately it’s easy to know which case you have in X-Plane:

• For OBJs, meshes live in VRAM!  (Who knew?)
• For everything else, they live in main memory.  This includes the terrain, forests, roads, facades, you name it.

Meshes In VRAM

If a mesh is in VRAM, the cost of drawing it is relatively unimportant.  My 4870 can draw just under 400 million triangles per second – and it’s probably limited by communication to the GPU.  And ATI has created two new generations of cards since the 4870.

Furthermore, mesh draw costs are only paid when they are drawn, so with some careful LOD you can get away with the occasional “huge mesh” – the GPU has the capacity if not everyone tries to push a million vertices at once.  (Obviously a million vertices in an autogen house that is repeated 500 times is going to cause problems.)

But there is a cost here, and it is – the VRAM itself!  A mesh costs 32 bytes per vertex (plus 4 bytes per index), so our mesh is going to eat at least 32 MB of VRAM.  That’s not inconsequential; for a user with a 256 MB card we just used up 1/8th of all VRAM on a single mesh.

One note about LOD here: the vertex cost of drawing is a function of what is actually drawn, so if we have a million-vertex high LOD mesh and a thousand-vertex low LOD mesh, we only burn a (small) chunk of our vertex budget when the high LOD is drawn.

But the entire mesh must be in VRAM to draw either LOD!  Only things drawn on screen have to be in VRAM, but textures and meshes go into VRAM as a whole, all LODs.  So we only save our 32 MB of VRAM by not drawing the object at all (e.g. it being farther away than the farthest LOD).

Meshes in Main Memory

For anything that isn’t an object, the mesh lives in main system memory, and is transferred over the PCIe bus when it needs to be drawn.  (This is sometimes called “AGP memory” because this could first be done when the AGP slot was invented.)  Here we have a new limitation: we can run out of capacity to transfer data on the PCIe slot.

Let’s go back to our mesh: our million vertex mesh probably takes around 32 MB.  It will have to be transferred over the bus each time we draw.  At 60 fps that’s over 1.8 GB of data per second.  A 16x PCIe 2.0 slot only has 8 GB/second of total bandwidth from the computer to the graphics card.  So we just ate 25% of the bus with our one mesh!  (In fact, the real situation is quite a bit worse; on my Mac Pro, even with simple performance test apps, I can’t push much more than 2.5 GB/second to the card, so we’ve really used 75% of our budget.)

On the bright side, storage in main memory is relatively plentiful, so if we don’t draw our mesh, there’s not a huge penalty.  Careful LOD can keep the total number of vertices emitted low.

Take-Away Points

• Non-OBJ vertex count is significantly more expensive than OBJ vertex count.
• OBJ meshes take up VRAM; the high LOD takes up VRAM even when the low LOD is in use.
• To reduce the cost of OBJ meshes, limit the total LOD of the object.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

View all posts by Ben Supnik →