How are 3D games so efficient? [closed]

Question

Patience, technical skill and endurance.

First point is that a DX Demo is primarily a teaching aid so it's done for clarity not speed of execution.

It's a pretty big subject to condense but games development is primarily about understanding your data and your execution paths to an almost pathological degree.

1. Your code is designed around two things - your data and your target hardware.
2. The fastest code is the code that never gets executed - sort your data into batches and only do expensive operations on data you need to
3. How you store your data is key - aim for contiguous access this allows you to batch process at high speed.
4. Parellise everything you possibly can
5. Modern CPUs are fast, modern RAM is very slow. Cache misses are deadly.
6. Push as much to the GPU as you can - it has fast local memory so can blaze through the data but you need to help it out by organising your data correctly.
7. Avoid doing lots of renderstate switches ( again batch similar vertex data together ) as this causes the GPU to stall
8. Swizzle your textures and ensure they are powers of two - this improves texture cache performance on the GPU.
9. Use levels of detail as much as you can -- low/medium/high versions of 3D models and switch based on distance from camera player - no point rendering a high-res version if it's only 5 pixels on screen.

In general, it's because

1. The games are being optimal about what they need to render, and
2. They take special advantage of your hardware.

For instance, one easy optimization you can make involves not actually trying to draw things that can't be seen. Consider a complex scene like a cityscape from Grand Theft Auto IV. The renderer isn't actually rendering all of the buildings and structures. Instead, it's rendering only what the camera can see. If you could fly around to the back of those same buildings, facing the original camera, you would see a half-built hollowed-out shell structure. Every point that the camera cannot see is not rendered -- since you can't see it, there's no need to try to show it to you.

Furthermore, optimized instructions and special techniques exist when you're developing against a particular set of hardware, to enable even better speedups.

The other part of your question is why a demo uses so much CPU:

... while a DX demo of a rotating Teapot @ 60fps uses a whopping 30% ?

It's common for demos of graphics APIs (like dxdemo) to fall back to what's called a software renderer when your hardware doesn't support all of the features needed to show a pretty example. These features might include things like shadows, reflection, ray-tracing, physics, et cetera.

This mimics the function of a completely full-featured hardware device which is unlikely to exist, in order to show off all the features of the API. But since the hardware doesn't actually exist, it runs on your CPU instead. That's much more inefficient than delegating to a graphics card -- hence your high CPU usage.

3D games are great at tricking your eyes. For example, there is a technique called screen space ambient occlusion (SSAO) which will give a more realistic feel by shadowing those parts of a scene that are close to surface discontinuities. If you look at the corners of your wall, you will see they appear slightly darker than the centers in most cases.

The very same effect can be achieved using radiosity, which is based on rather accurate simulation. Radiosity will also take into account more effects of bouncing lights, etc. but it is computationally expensive - it's a ray tracing technique.

This is just one example. There are hundreds of algorithms for real time computer graphics and they are essentially based on good approximations and typically make a lot assumptions. For example, spatial sorting must be chosen very carefully depending on the speed, typical position of the camera as well as the amount of changes to the scene geometry.

These 'optimizations' are huge - you can implement an algorithm efficiently and make it run 10 times faster, but choosing a smart algorithm that produces a similar result ("cheating") can make you go from O(N^4) to O(log(N)).

Optimizing the actual implementation is what makes games even more efficient, but that is only a linear optimization.

Eeeeek!

I know that this question is old, but its exciting that no one has mentioned VSync!!!???

You compared the CPU usage of the game at 60fps to CPU usage of the teapot demo at 60fps.

Isn't it apparent, that both run (more or less) at exactly 60fps? That leads to the answer...

Both apps run with vsync enabled! This means (dumbed-down) that the rendering framerate is locked to the "vertical blank interval" of your monitor. The graphics hardware (and/or driver) will only render at max. 60fps. 60fps = 60Hz (Hz=per second) refresh rate. So you probably use a rather old, flickering CRT or a common LCD display. On a CRT running at 100Hz you will probably see framerates of up to 100Hz. VSync also applies in a similar way to LCD displays (they usually have a refresh rate of 60Hz).

So, the teapot demo may actually run much more efficient! If it uses 30% of CPU time (compared to 50% CPU time for GTA IV), then it probably uses less cpu time each frame, and just waits longer for the next vertical blank interval. To compare both apps, you should disable vsync and measure again (you will measure much higher fps for both apps).

Sometimes its ok to disable vsync (most games have an option in its settings). Sometimes you will see "tearing artefacts" when vsync is disabled.

You can find details of it and why it is used at wikipedia: http://en.wikipedia.org/wiki/Vsync

Whilst many answers here provide excellent indications of how I will instead answer the simpler question of why

• GTA4 took $400 Million dollars in it's first week
• Crytech wrote an extremely impressive graphics demo to allow nVidia to 'show off' at a trade show. The resulting impressions got them the leg up to create what would become FarCry.
• Valve's 2005 revenue and operating profit have been stated as 70 and 55 million USD respectively.

Perhaps the best example (certainly one of the best known) is Id software. They realised very early, in the days of Commander Keen (well before 3D) that coming up with a clever way to achieve something¹, even if it relied on modern hardware (in this case an EGA graphics card!) that was graphically superior to the competition that this would make your game stand out. This was true but they further realised that, rather than then having to come up with new games and content themselves they could licence the technology, thus getting income from others whilst being able to develop the next generation of engine and thus leap frog the competition again.

The abilities of these programmers (coupled with business savvy) is what made them rich.

That said it is not necessarily money that motivates such people. It is likely just as much the desire to achieve, to accomplish. The money they earned in the early days simply means that they now have time to devote to what they enjoy. And whilst many have outside interests almost all still program and try to work out ways to do better than the last iteration.

Put simply the person who wrote the teapot demo likely had one or more of the following issues:

• less time
• less resources
• less reward incentive
• less internal and external competition
• lesser goals
• less talent

The last may sound harsh² but clearly there are some who are better than others, bell curves sometimes have extreme ends and they tend to be attracted to the corresponding extreme ends of what is done with that skill.

The lesser goals one is actually likely to be the main reason. The target of the teapot demo was just that, a demo. But not a demo of the programmers skill³. It would be a demo of one small facet of a (big) OS, in this case DX rendering.

To those viewing the demo it wouldn't mater it it used way more CPU than required so long as it looked good enough. There would be no incentive to eliminate waste when there would be no beneficiary. In comparison a game would love to have spare cycles for better AI, better sound, more polygons, more effects.

---

1. in that case smooth scrolling on PC hardware
2. Likely more than me so we're clear about that
3. strictly speaking it would have been a demo to his/her manager too, but again the drive here would be time and/or visual quality.

Because of a few reasons

• 3D game engines are highly optimized
• most of the work is done by your graphics adapter
• 50% Hm, let me guess you have a dual core and only one core is used ;-)

EDIT: To give few numbers

2.8 Ghz Athlon-64 with NV-6800 GPU. The results are:

• CPU: 72.78 Mflops
• GPU: 2440.32 Mflops