Understanding Timing Data in PVRTune¶

Timing data can be made visible on a graph by choosing the Render Timing Data option from the action menu displayed when right-clicking the graph (see Change the Graph Rendering Options). This is enabled by default.

The images in this section show examples of captured timing data. The timing data is arranged on several timelines, each with its own label.

The Tiler timeline represents the Tile Accelerator (TA) core time. This is a measure of the time spent in tiling/culling the frame and running vertex shaders.
The Renderer timeline represents Render time. This is a measure of how much time is spend fetching textures processing fragment shaders, and other fragment processing tasks.

These timelines represent the two main stages in the Tile-Based Deferred Rendering process.

Note

In addition to the Tiler and Renderer timelines, there can also be others depending on the hardware being profiled. A summary of hardware-specific terms is provided in Hardware Terms.

Each block displayed in the representation of the timing data corresponds to a given task or activity within a frame and is colour coded to make the frame, process ID, and work target easily identifiable. In addition to Tiler and Renderer timing data, there may also be other sets of data for transfer tasks, 2D core time (for chips with dedicated 2D cores), compute time (for PowerVR Series6 onwards), and custom timing data sent using PVRScope.

View Details of Timing Data¶

A wide range of information can be gained from the timing data by holding the mouse pointer over a task in the timeline. The information displayed this way shows the:

process ID;
frame number;
total number of tasks on each timeline (such as Tiler and Renderer) that can be attributed to the same frame;
time spent on each task;
time spent processing a set of tasks;
total time spent processing the frame.

Selecting a task shows more details in the Properties window.

Tasks in PVRTune¶

Blocks in the graph view of PVRTune are used to represent tasks.

Task Colour Coding¶

The displayed timing data is colour coded to make it easier to interpret. Blocks of the same central colour represent a single frame, where the colours are recycled every sixteen frames.

In addition to the general colour of a block, its top and bottom tips are also coloured.

The top tip represents the process ID, where different colours indicate different process IDs.
The bottom tip represents the work target, where for 2D/Tiler/Renderer tasks, different colours indicate different renderer targets.

The image below provides an example of task colour coding used in the display of timing data. The core colour of a task represents a single frame.

Each frame is given:

a core colour - (a)
an associated process - (b)
a render target - (c)

Repeated top tip colours refer to the same process ID.

In the image above, the tasks were generated by one process. This is indicated through the use of a single colour (pale blue) across the top tips. Repeated bottom tip colours refer to the same render targets.

Three render targets are present, and these are indicated by the three colours used for the bottom tips of the tasks. In double or triple buffered situations, the render targets are different for each frame, alternating between each of the back buffer targets.

Transfer Tasks¶

Transfer tasks represent the time spent processing tasks related to copying of memory, such as blitting or texture uploading. The image below shows an example where a series of transfer tasks are displayed as timing data.

Driver Timing Data¶

Driver timing data becomes relevant when PVRTune is used in combination with PVRCarbon. The data is displayed in its own timeline and is represented as a series of tasks labelled with the thread ID that called the driver. An example of driver timing data is provided is shown below.

Note

By default, only the most expensive calls are displayed, such as glDrawElements, glReadPixels, shader compilation, and texture uploads.

Warning

Setting API Function Timing Events to Verbose may affect performance.

Events in PVRTune¶

Various events can occur while analysing an application with PVRTune. Some of these events can be shown in the graph view.

Active Counters Changed¶

This event represents the point at which the active counter group has been changed using some custom hardware counter group. The event appears as a vertical grey line.

Event Ordinal Reset¶

This event is usually hidden by active counters changed. The event represents a change in the ordering of the counters or counter sources read by PVRPerfServer, and appears as a vertical green line.

Custom Mark¶

Custom marks are marks that have been sent to PVRTune either by a PVRScope enabled application (displayed in the relevant PVRScope Timeline) or by pressing the m key in PVRPerfServer (displayed in the PVRScope/PVRPerfServer Timeline). A custom mark appears as a vertical red line.

Power-off Period¶

Power-off periods are represented by vertical grey blocks in the graph view. These events occur when the hardware has gone to sleep or powering down to save power due to a lack of work.

Data Loss Period¶

A data loss period is one during which PVRTune has lost data from the driver. A data loss period is represented as a vertical green block. There are several ways to minimise data loss, such as:

Decreasing the device CPU load;
Altering the PVRPerfServer data read rate using the -c command-line option;
There could be congestion on the network the data is being transmitted on. This can be alleviated by using a less congested network or by attempting ad-hoc networking;
Saving data to a file rather than send it over the network. See the Command-Line Options section for the --sendto= command-line option for PVRPerfServer.
Reducing the data quantity. This can be achieved by disabling the --periodic= or --graphics= option via the PVRPerfServer command-line.

Note

PVRPerfServer command-line options can also be set remotely from PVRTune.

Smart Parameter Management Mode¶

The Smart Parameter Management (SPM) mode is used to manage parameters when the buffer fills. A Renderer task labelled “Renderer SPM task” appears when this mode is activated.