hjd | 0304f11 | 2016-11-14 22:36:53 | [diff] [blame] | 1 | # GPU Memory Tracing |
| 2 | |
| 3 | This is an overview of the GPU column in [MemoryInfra][memory-infra]. |
| 4 | |
| 5 | [TOC] |
| 6 | |
| 7 | ## Quick Start |
| 8 | |
| 9 | If you want an overview of total GPU memory usage, select the GPU process' GPU |
| 10 | category and look at the _size_ column. (Not _effective size_.) |
| 11 | |
| 12 | ![Look at the size column for total GPU memory][gpu-size-column] |
| 13 | |
| 14 | [memory-infra]: README.md |
| 15 | [gpu-size-column]: https://storage.googleapis.com/chromium-docs.appspot.com/c7d632c18d90d99e393ad0ade929f96e7d8243fe |
| 16 | |
| 17 | ## In Depth |
| 18 | |
| 19 | GPU Memory in Chrome involves several different types of allocations. These |
| 20 | include, but are not limited to: |
| 21 | |
| 22 | * **Raw OpenGL Objects**: These objects are allocated by Chrome using the |
| 23 | OpenGL API. Chrome itself has handles to these objects, but the actual |
| 24 | backing memory may live in a variety of places (CPU side in the GPU process, |
| 25 | CPU side in the kernel, GPU side). Because most OpenGL operations occur over |
| 26 | IPC, communicating with Chrome's GPU process, these allocations are almost |
| 27 | always shared between a renderer or browser process and the GPU process. |
| 28 | * **GPU Memory Buffers**: These objects provide a chunk of writable memory |
| 29 | which can be handed off cross-process. While GPUMemoryBuffers represent a |
| 30 | platform-independent way to access this memory, they have a number of |
| 31 | possible platform-specific implementations (EGL surfaces on Linux, |
| 32 | IOSurfaces on Mac, or CPU side shared memory). Because of their cross |
| 33 | process use case, these objects will almost always be shared between a |
| 34 | renderer or browser process and the GPU process. |
| 35 | * **GLImages**: GLImages are a platform-independent abstraction around GPU |
| 36 | memory, similar to GPU Memory Buffers. In many cases, GLImages are created |
| 37 | from GPUMemoryBuffers. The primary difference is that GLImages are designed |
| 38 | to be bound to an OpenGL texture using the image extension. |
| 39 | |
| 40 | GPU Memory can be found across a number of different processes, in a few |
| 41 | different categories. |
| 42 | |
| 43 | Renderer or browser process: |
| 44 | |
| 45 | * **CC Category**: The CC category contains all resource allocations used in |
| 46 | the Chrome Compositor. When GPU rasterization is enabled, these resource |
| 47 | allocations will be GPU allocations as well. See also |
| 48 | [docs/memory-infra/probe-cc.md][cc-memory]. |
| 49 | * **Skia/gpu_resources Category**: All GPU resources used by Skia. |
| 50 | * **GPUMemoryBuffer Category**: All GPUMemoryBuffers in use in the current |
| 51 | process. |
| 52 | |
| 53 | GPU process: |
| 54 | |
| 55 | * **GPU Category**: All GPU allocations, many shared with other processes. |
| 56 | * **GPUMemoryBuffer Category**: All GPUMemoryBuffers. |
| 57 | |
| 58 | ## Example |
| 59 | |
| 60 | Many of the objects listed above are shared between multiple processes. |
| 61 | Consider a GL texture used by CC --- this texture is shared between a renderer |
| 62 | and the GPU process. Additionally, the texture may be backed by a GLImage which |
| 63 | was created from a GPUMemoryBuffer, which is also shared between the renderer |
| 64 | and GPU process. This means that the single texture may show up in the memory |
| 65 | logs of two different processes multiple times. |
| 66 | |
| 67 | To make things easier to understand, each GPU allocation is only ever "owned" |
| 68 | by a single process and category. For instance, in the above example, the |
| 69 | texture would be owned by the CC category of the renderer process. Each |
| 70 | allocation has (at least) two sizes recorded --- _size_ and _effective size_. |
| 71 | In the owning allocation, these two numbers will match: |
| 72 | |
| 73 | ![Matching size and effective size][owner-size] |
| 74 | |
| 75 | Note that the allocation also gives information on what other processes it is |
| 76 | shared with (seen by hovering over the green arrow). If we navigate to the |
| 77 | other allocation (in this case, gpu/gl/textures/client_25/texture_216) we will |
| 78 | see a non-owning allocation. In this allocation the size is the same, but the |
| 79 | _effective size_ is 0: |
| 80 | |
| 81 | ![Effective size of zero][non-owner-size] |
| 82 | |
| 83 | Other types, such as GPUMemoryBuffers and GLImages have similar sharing |
| 84 | patterns. |
| 85 | |
| 86 | When trying to get an overview of the absolute memory usage tied to the GPU, |
| 87 | you can look at the size column (not effective size) of just the GPU process' |
| 88 | GPU category. This will show all GPU allocations, whether or not they are owned |
| 89 | by another process. |
| 90 | |
| 91 | [cc-memory]: /docs/memory-infra/probe-cc.md |
| 92 | [owner-size]: https://storage.googleapis.com/chromium-docs.appspot.com/a325c4426422e53394a322d31b652cfa34231189 |
| 93 | [non-owner-size]: https://storage.googleapis.com/chromium-docs.appspot.com/b8cf464636940d0925f29a102e99aabb9af40b13 |