[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Identify your most expensive render passes\n\nThe AGI Frame Profiler lets you examine individual render passes that are used to compose a single frame of your app. It does this by intercepting and recording all the state necessary for executing each graphics API call. On Vulkan this is done natively using Vulkan's layering system. On OpenGL, commands are intercepted using ANGLE, which converts OpenGL commands to Vulkan calls so that they can be executed on the hardware.\n\nAdreno devices\n--------------\n\nTo identify your expensive render passes, first look at AGI's timeline view at the top of the window. This shows all the render passes that comprise the composition of a given frame chronologically. It's the same view that you would see in the System Profiler if you had GPU Queue information. It also presents basic information about the render pass, such as the resolution of the framebuffers being rendered to, which can provide some insight into what's happening in the render pass itself.\n**Figure 1.**Frame Timeline view\n\nThe first criteria you can use to investigate your render passes is how much time they are taking. The longest render pass will most likely be the render pass with the largest potential for improvement, so start by taking a look at that one.\n**Figure 2.**Identifying the longest render pass in the Frame Timeline view\n\nThe GPU slice pertaining to the relevant render pass will already present some information on what is happening within the render pass:\n\n1. Binning: Where vertices are placed into bins based on where they land on screen\n2. Rendering: Where pixels or fragments are shaded\n3. GMEM load/store: When the contents of a framebuffer are loaded or stored from internal GPU memory to main memory\n\nYou can get a good idea of where potential bottlenecks may be by looking at how\nmuch time each of these takes within the render pass. For example:\n\n- If Binning takes up a large portion of time, this suggests a bottleneck with vertex data which suggests too many vertices, large vertices, or other issues related to vertices.\n- If Rendering takes up a majority of time, this suggests that shading is the bottleneck. Possible causes may be complex shaders, too many texture fetches, rendering to a high resolution framebuffer when it's not necessary, or other related issues.\n\nGMEM loads and stores are also something to keep in mind. It's expensive to move things from graphics memory to main memory, so minimizing the amount of load or store operations will help with performance as well. A common example of this is having a GMEM store\ndepth/stencil, which writes out the depth/stencil buffer to main memory; if\nyou're not using that buffer in future render passes, this store operation can\nbe eliminated and you will save on frame time and memory bandwidth.\n**Figure 3.**Identifying GMEM loads and stores\n\nLarge render pass investigation\n-------------------------------\n\nTo see all of the individual draw commands issued during the render pass:\n\n1. Click the render pass in the timeline.\n This open the render pass in the hierarchy found in the **Commands** pane of\n the **Frame Profiler**.\n\n2. Click the render pass's menu, which displays all the individual draw\n commands issued during the render pass. If this is an OpenGL application,\n you can dig even further and see the Vulkan commands issued by ANGLE.\n\n**Figure 4.**Commands pane\n\nSelect one of the draw calls. This opens the **Framebuffer** pane, which\nshows all the framebuffer attachments that were bound during this draw, and the final result of the draw on the attached framebuffer. Here you can also use AGI to open both the previous and next draw calls, and compare the difference between the two. If they're visually almost identical, this suggests an opportunity to eliminate a draw call that doesn't contribute to the final image.\n**Figure 5.**Selecting individual draw calls in the Commands pane\n\nOpening the **Pipeline** pane for this draw shows the state used by the graphics\npipeline to execute this draw call.\n**Figure 6.**Pipeline pane\n\nThe **Input Assembler** provides information about how vertex data was bound to this draw. This is a good area to investigate if you noticed that Binning takes up a large portion of your render pass's time; here you can get information about vertex format, the number of vertices drawn, and how vertices are laid out in memory. For more information on this, see [Analyze vertex formats](/agi/frame-trace/vertex-formats).\n**Figure 7.**Input Assembler section in the Pipeline pane\n\nThe **Vertex Shader** section provides information about the vertex shader you\nused during this draw, and can also be a good place to investigate if binning\nwas identified as an issue. You can see the SPIR-V and decompiled GLSL of the\nshader used, and investigate the bound **Uniform Buffers** for this call. See\nSee [Analyze shader performance](/agi/frame-trace/shader-performance) for more details.\n**Figure 8.**Vertex Shader section in the Pipeline pane\n\nThe **Rasterizer** section shows you information about the more fixed-function\nsetup of the pipeline, and can be used more for debugging purposes of\nfixed-function state such as viewport, scissor, depth state, and polygon mode.\n**Figure 9.**Rasterizer section in the Pipeline pane\n\nThe **Fragment Shader** section provides a lot of the same information that is\nfound in the **Vertex Shader** section, but specific to the **Fragment Shader**.\nIn this case, you can actually see which textures are being bound and\ninvestigate them by clicking the handle.\n**Figure 10.**Fragment Shader section in Pipeline pane\n\nSmaller render pass investigation\n---------------------------------\n\nAnother criteria you can use to improve your GPU performance is looking at groups of smaller render passes. In general you want to minimize the amount of render passes as much as possible, because it takes time for the GPU to update state from one render pass to another. These smaller render passes are usually used to do things like generate shadow maps, apply gaussian blur, estimate luminance, do post processing effects, or render the UI. Some of these can potentially be consolidated into a single render pass, or even eliminated entirely if they do not affect the overall image enough to justify the cost.\n**Figure 11.**Smaller render passes used to downsample the native resolution buffer"]]