What are render graphs?
A typical application frame is rendered using multiple GPU processing tasks, or workloads. Later workloads consume the output of earlier ones to build up the final image that is shown on the screen.
Render graphs, as generated by Frame Advisor’s Render Graph view, provide a visual summary of the relationships between GPU workloads and the resources (data) passed between workloads. This visualization is in the form of a web of operations called a
Directed Acyclic Graph (DAG)
. This includes:
- Workloads, such as render passes, or transfer operations.
- Resources, such as textures, which are generated by one workload and which may be consumed by a later workload.
- Frame output, which is the final image sent to the swapchain.
When are render graphs useful?
Render graphs can help diagnose:
- Unnecessary computation, including:
- Generation of textures which are not used in the final image (the data sent to the swap chain).
- Over-complex collections of render passes or other forms of computation.
- Unnecessary data resource reads or writes.
- Excessively large inputs or outputs. For example, render graphs will give the resolution of textures which are used in the production of the frame.
Both of these issues can lead to an increase in GPU load and/or bandwidth.
What are the limitations of render graphs?
Many performance issues cannot be seen in render graphs, or can be better seen elsewhere. For example, render graphs should not be used to diagnose:
- Over-complex or inefficient geometry (use the Detailed Metrics view and the Mesh view).
- Inefficient choices of API parameters (use the API Calls view).
- Inefficient shader code.
However, render graphs are often a good place to start an investigation of poor performance. If a render graph proves not to be useful, you can move on to using other Frame Advisor views. These have complementary strengths.
It is important to understand which view, or which combination of views, may be most useful for investigation of a problem.
Below are some things to consider for each view:
- The Framebuffer view shows an image for each attachment relating to a specific draw call. It also gives the sizes of those attachments. However, unlike the render graph view, it doesn’t show the relationships between attachments and render passes.
- The Content Metrics view lists render passes used to construct a frame in a similar manner to the Render Graph view. It summarizes various statistics, but unlike the Render Graph view and similar to API Calls, it does not show details of inputs and outputs.
- The API Calls view describes, in order, the specific Vulkan/OpenGL ES functions used to construct a frame. This gives far more detailed information relating to each call than a render graph will. However, it is easy to get lost in this detailed information.
For details of these other Frame Advisor views and others, refer to
Get started with Arm Performance Studio for mobile
.