Profiling Direct3D apps for Windows Phone 8

  • [アーティクル]

[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]

When you launch Windows Phone Application Analysis while you’re working on a Direct3D app in Visual Studio, you see different options and different reports than when you’re profiling a managed app. The native code profiler uses the profiling technology built into Visual Studio 2012 and stores its results in standard .vspx files.

You can also profile a Windows Phone Runtime Component project that’s referenced from a C# or Visual Basic project with the native code profiler.

For an introduction to profiling for Windows Phone based on the profiler for managed apps, see App profiling for Windows Phone 8. For more info about developing Direct3D apps, see Direct3D app development for Windows Phone 8.

This topic contains the following sections.

Start app profiling for a Direct3D app

To start app profiling for a Direct3D app

  1. You can run app profiling by using one of the following methods. These methods assume that you have a Direct3D project open in Visual Studio.

    • From the DEBUG menu, select Start Windows Phone Application Analysis.

    • Press Alt-F1.

  2. Only the Execution option is available for Direct3D apps.

  3. Click Start Session.

    Your app starts to run on the selected emulator or device.

The following illustration shows the screen to start app profiling for a Direct3D app.

Stop app profiling

After you’ve profiled an adequate sampling of activities, click End Session.

After you stop the profiling session, the tool copies, parses, and analyzes the data that it has gathered. Then it displays the Summary view of results, as shown in the following illustration.

Parsing the profiling data and preparing the reports takes longer when you profile your app on a phone than when you profile your app on the emulator.

Collecting and analyzing custom events

You can configure the native profiler to collect custom events. Then you can review these events in Windows Performance Analyzer.

To collect and analyze custom events

  1. Make sure you have the Windows Performance Toolkit from the Windows Software Development Kit (SDK) for Windows 8.

  2. With the Message Compiler (MC.exe) tool, consume the manifest file for the custom events and generate the header file (.h file) and resource file (.resx) to be used in your code.

  3. Add the generated header file (.h file) and resource file (.resx) to your project. Use them in your code to register or unregister the custom events.

  4. Use the Wevtutil.exe tool to register the manifest with the event logger. A typical command line is similar to the following:

    wevtutil im <manifest file> /rf:<full path to dll/exe which includes the resources> /mf:<same path as rf>

    If you are updating the manifest, first you have to uninstall it. To uninstall the manifest, run the command wevtutil rm <manifest>.

  5. Add the custom GUID to the file ProfilerTasks.XML file located in the following folder:

    %ProgramFiles(x86)%\Common Files\Microsoft Shared\Phone Tools\11.0\Profiler\target

    A typical entry is similar to the following:

    <EtwProvider Name="CustomEventProducer" GUID="{708BA62D-5B10-4309-AA23-ADC794E60F6C}" />

    Editing this file requires administrative privileges.

  6. Return to Visual Studio and start profiling your app by pressing Alt+F1 or by selecting Start Windows Phone Application Analysis from the DEBUG menu.

    After profiling, the logs are stored inside the .vspx file for the profiling session. This file is found in the project directory.

  7. Change the file extension of the .vspx file to .zip, then unzip the .vspx file and extract the .etl logs. The logs are found within the file in the following path:

    VSProfilingData\VSPerfLog*.etl

  8. Open the extracted .etl file in your preferred ETW file viewer for Windows 8, such as Windows Performance Analyzer. For more info, see Windows Performance Analyzer (WPA).

  9. Instantiate the Generic Events graph to review the custom event data.

Collecting and analyzing Qualcomm events

You can collect events raised by the Qualcomm graphics driver with the native profiler. Then you can review these events in Windows Performance Analyzer.

Events raised by the Qualcomm graphics driver are enabled by default.

To collect and analyze Qualcomm events

  1. Make sure you have the Windows Performance Toolkit from the Windows Software Development Kit (SDK) for Windows 8.

  2. Open your app in Visual Studio and start profiling by pressing Alt+F1 or by selecting Start Windows Phone Application Analysis from the DEBUG menu.

    After profiling, the logs are stored inside the .vspx file for the profiling session. This file is found in the project directory.

  3. Change the file extension of the .vspx file to .zip, then unzip the .vspx file and extract the .etl logs. The logs are found within the file in the following path:

    VSProfilingData\VSPerfLog*.etl

  4. Open the extracted .etl file in your preferred ETW file viewer for Windows 8, such as Windows Performance Analyzer. For more info, see Windows Performance Analyzer (WPA).

  5. In Graph Explorer, expand System Activity to display Generic Events. Then drag Generic Events onto the Analysis window.

  6. In the Analysis window, expand the QCOM DX9 UMD provider to see Qualcomm events.

    The task names that are displayed represent the events that were logged. You can use Windows Performance Analyzer to change the scope of the view to specific frames and so forth.

Qualcomm events

These events provide information about internal operations performed by the Qualcomm graphics driver. They can be used to better understand whether your code is driving the GPU efficiently, or whether it is inadvertently causing the driver to do expensive housekeeping work.

Task name

Task description

GMemStore

Indicates when renderering results are written from the GPU cache back to system memory.Pushes render data to system memory.

GMemLoad

Takes previously rendered bits from system memory & loads them to the GPU cache.

CmdBufferFlush

Represents a command buffer flush where rendering commands generated by the CPU (in response to D3D API calls) are sent to the GPU hardware to be executed. Many flushes indicate less parallelism.

ResourceDiscardWarning

Indicates that the renaming limit has been reached for a given allocation and that all existing renames are still in use. This event is a performance warning because under these conditions the driver performs a stalling lock. This typically indicates that too much dynamic data is being transferred from CPU to GPU.

QueryNotSignaled

Applies to API queries. This event warns that GetData was called before the query was done. Repeated occurrences of this event indicate that the app is not doing enough work between issuing the query and trying to get results.

OutOfMemory

Insufficient memory was available for the graphics driver to complete an operation.Insufficient system memory or video memory was allocated.

MismatchedConfig

Indicates that the application specified a depth buffer and render targets with incompatible sizes or formats.The runtime doesn’t prevent this situation. It will probably result in some unexpected visual artifact.

Qualcomm flush reasons

This enumeration provides additional information about the cause of a CmdBufferFlush event.

Message

Description

Explicit

The flush was explicitly requested (for example, by calling Present at the end of the scene).

OutOfSpace

There is no more available space in the command buffer of the GPU hardware.

OutOfHandles

Refers to allocation handles that describe all the memory referenced in a command buffer. Typically this event indicates that a lot of rendering was batched. While batching is a recommended practice, this event indicates that flushes due to handle exhaustion are happening a lot batching may be excessive for a given application.

ExternalDependency

Indicates that there is an inter-engine dependency causing the flush – for example, 3D rendering to a surface followed by a video processing (DXVA) operation. This sequence of operations requires that the 3D rendering is flushed before the video processing operation so the scheduler sees the required signals and waits. This is the flush initiated by the video UMD.

AllocationReferenced

This flush is triggered when a resource allocation that was written to by the GPU is referenced by some other hardware unit or by the CPU. Previous GPU rendering must be flushed before any other references to the allocation can be allowed to proceed.

Video

Indicates that the video driver requested the GPU to perform some rendering work.