PVRTuneComplete GUI¶
This section details the new GUI features available with PVRTuneComplete.
The Properties Window in PVRTuneComplete¶
The Properties window displays the properties of items that have been selected. This could be the properties of a counter selected from the Counter Table or graph, or the properties of a timing task selected from the graph.
By default, this window is placed on the bottom left of the GUI. Counter properties will usually consist of:
a brief description - what it is and what the value means;
the inputs used to create the counter - the hardware and software counters;
the equation - how the inputs are combined to produce the displayed value.
Depending on which timing task has been selected, the timing task properties will likely consist of:
Process Identifier (PID);
Frame number;
Task name - i.e. renderer, tiler, etc.;
duration in milliseconds;
render target data - i.e. dimensions, format, etc.;
shader information - i.e. vertex and fragment shader source, etc.;
synchronisation objects.
The Timelines Window in PVRTuneComplete¶
Each timeline represents a history of events that have been emitted by the driver and subsequently captured by PVRTune over the course of a profiling session.
The settings in the PVRPerfServer Details window affect which timelines will be created in PVRTune. Enabling more data streams will increase the number of timelines available.
Having all the timelines displayed in the graph may become overwhelming, so the Timelines docking window can be used to show or hide individual timelines. By default, the Timelines window is placed bottom right.
The window splits the available timelines into several subsections.
HW Core (Hardware Core)¶
These timelines track timing events emitted by GPU hardware blocks. These include:
Compute;
2D renderer;
3D renderer;
Tile accelerator.
HW Queue (Hardware Queue)¶
These timelines track timing events emitted by various hardware queues. There is one per hardware core. Each queue holds pending work submitted by the driver to the GPU for execution. These timelines require synchronisation objects to be enabled, as the queues are built from the data retrieved from synchronisation objects.
The PVRTune visualisation packs the queued tasks into the fewest number of levels; newly submitted tasks will be displayed on a free level or a new level. It’s important to note that the level has no meaning, only the horizontal placement (i.e. time) of the task. The queue depth at any time point is given by the number of tasks stacked vertically at that point in the x-axis.
Host (User Mode)¶
These timelines track timing events emitted by the host client driver, which are generated by API calls from OpenGL ES, EGL, and services (UM). These include glBindFramebuffer, glDraw*, eglSwapBuffers, TA kick, and texture upload events.
Host (kernel Mode)¶
These timelines track timing events emitted by the host kernel driver (services). As an example, this could be enqueue events such as services scheduling work for the GPU.
Sync Objects¶
These timelines track synchronisation objects (one per object) and the events emitted by the driver for each object. For example - object creation, destruction, update, check fail, and check pass.
Shader Source Window in PVRTuneComplete¶
The compiler Source View window displays the GLSL shader source code associated with a particular task. It includes syntax highlighting and the cycle count on the side bar.
Note
Some DDK versions do not support emission of GLSL. With these versions, the shader source is unavailable.
This window can be accessed from the properties window of a task. Starting from the timing graph, select a timing task to display its properties window then select ‘GLSL source’ to display the viewer window.
Note
If the GLSL shader source does not appear it is likely that glCompileShader calls have not been captured by PVRTune. These calls normally occur during initialisation, so starting the capture process earlier usually resolves this issue.
If profiling compilers are available, the shader info section can also display various GLSL compiler performance statistics, as shown below. These statistics include:
The percentage of USC utilisation;
The number of cycles;
Wait stall.
To setup offline profiling compilers, select Edit from the menu bar, then Preferences, followed by Select compiler directory. The location of the compiler library can then be chosen.
Streams Window in PVRTuneComplete¶
The Streams window is visible only in the Complete version of PVRTune. It lists all the data streams coming from PVRPerfServer. Three stream types can come from the Driver Development Kit (DDK): firmware, host, and client. Only client is listed per-PID.
PVRPerfServer sends another stream which details CPU/memory usage information, as do any PVRScope connections.
If Automatic mode is turned off, streams can be manually regrouped by dragging and dropping them. The groupings should be by time domain, also known as clock source. This means that streams which share a common time-value origin (at zero at the same time), and which increase at the same rate, should be grouped.
Command-Line Arguments¶
PVRTuneComplete has additional command-line arguments available to it beyond those listed in the Command-Line Arguments section. The following arguments are available to PVRTuneComplete:
Argument |
Description |
|---|---|
|
Save a counter group from the Edit Counter Groups dialog in the GUI. Expects a string as a filename (file is saved as .pvrtunecg). |
|
Same function as “File > Export > Export raw data to CSV” in the GUI. Expects a string as a filename (file is saved as .csv). |
|
Same function as “File > Export > Export active counters to CSV” in the GUI. Expects a string as a filename (file is saved as .csv). |
|
Same function as “File > Export > Export marks to CSV” in the GUI. Expects a string as a filename (file is saved as .csv). |
|
Same function as “File > Export > Export user counters to CSV” in the GUI. Expects a string as a filename (file is saved as .csv). |
|
Same function as “File > Export > Export user timing to CSV” in the GUI. Expects a string as a filename (file is saved as .csv). |
|
Same function as “File > Export > Export counter definitions to CSV” in the GUI (also available from “CSV” Export” in Edit Counter Groups dialog. Expects a string as a filename (file is saved as .csv). |
|
Same function as “File > Export > Export task timing data to CSV” in the GUI. Expects a string as a filename (file is saved as .csv). |
|
Same function as “File > Export > Export frame timing data to CSV” in the GUI. Expects a string as a filename (file is saved as .csv). |
|
Load counter/group definitions from the specified input file. Same function as “Load” (for .pvrtunecg) or “CSV Import” (for .csv) in the Edit Counter Groups dialog in the GUI. Expects a string as a filename (either .pvrtunecg or .csv). |
Shared Context Editor¶
Note
This feature should not be needed when using rogueddk 1.19 or newer.
The Shared Context Editor window can be used to make PVRTune aware of shared contexts within an application recorded on an older DDK. This is for when an application shares EGL contexts using the share_context parameter in eglCreateContext(), but the driver was unable to transmit this data.
The window will show a drop-down list of processes along with the various EGL Contexts created by that process. The Context ID drop-down is used to select the Context from which data is shared, the list on the left will show the other contexts in the application that can receive the shared data, while the list on the right lists the context(s) that the currently selected context is sharing with. These Context IDs can then be moved back and forth with the respective buttons in the middle to respectively associate/dissociate contexts.
The Shared Context Editor window is available from the Edit menu in the menu bar.