A couple of weeks ago, I took a brief trip to Liverpool for Develop, a conference for games developers. I’ve already blogged about the stunning 3D gaming demo on Sony PlayStation, how one studio took three years to evolve its game, and 15 top tips for creating netbook games. Let me now tell you about the session on optimising games, run by Leigh Davies of Intel.
He introduced Graphics Performance Analyzers (GPA), a suite of three tools that you can use to understand how your game is working on the hardware. The suite evolved out of Intel’s own toolbox, used whenever Intel was called in to advise clients on how software performance could be improved. Because the Intel team hadn’t been working on the project during its development, a tool was needed that could give them a quick understanding of the resources the software is using.
The first tool Davies introduced was the System Analyzer. This provides real time metrics as the game runs, in three categories. The first covers CPU use, including core usage. If you have a multicore system, it will show you how busy each core is. The second group of metrics covers DirectX, and the last set covers GPU metrics. Although the tool is hardware-agnostic, the GPU metrics are only available on Intel hardware because the software uses features of the chip to expose additional data. If your frame rates are dropping, you can use this tool to see which metrics spike, which helps identify the bottleneck. You can also do real time overrides, such as overdraw analysis, null hardware, null driver and texture simplification.
The second tool, Frame Analyzer, is used to investigate part of a game or a scene in more depth. It provides data on every DirectX call used to build the scene, so that you can experiment with it, and presents that data as a graph. The erg list shows any item that renders a pixel, draws, clears or copies a surface so that you can see the metrics for that draw call. The render targets affected by those draw calls can then be shown. The command list is replayed so that you can see the average and range of draw call timings, which helps you know how much confidence you should have in a particular draw call. You can also change how any draw call is represented in the scene, so you can make it a highlighted colour, wireframe it, or scrub previous calls.
The third tool is a beta preview called Platform View. This provides a top-down analysis of all tasks and threads running on the system, and aims to show in one place everything that’s happening on the system. It enables you to instrument your code so that you can get a timeline view of what’s going on in-depth, although Davies said that the instrumentation isn’t essential. You could take a game off the shelf in a shop and run Platform View to get a certain amount of information about what’s going on under the hood.
Graphics Performance Analyzers runs in a client-server model, which means you can run it on any PC, run the game on another PC and connect them using a network. There is a small overhead of running GPA, but the client-server model means that’s kept to a minimum, and enables you to easily run the monitoring on lots of machines. The shim layer used is smart enough to cope with things like Steam, and ensure that only the final game (and not the starter menu) is instrumented and analysed.
Although GPA has a value of $299, you can get it free if you register as a developer. Intel has about 12 people working on the tool and releases a new version each year, around the time of GDC, so it’s a fully supported product. If you need to identify bottlenecks in a game so that you can strike the right balance between visual quality and performance, why not give it a go?