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. |
Colin Blundell | 5007feef | 2023-07-20 14:57:29 | [diff] [blame] | 35 | * **SharedImages**: SharedImages are a platform-independent abstraction around GPU |
| 36 | memory, similar to GPU Memory Buffers. In many cases, SharedImages are created |
| 37 | from GPUMemoryBuffers. |
hjd | 0304f11 | 2016-11-14 22:36:53 | [diff] [blame] | 38 | |
| 39 | GPU Memory can be found across a number of different processes, in a few |
| 40 | different categories. |
| 41 | |
| 42 | Renderer or browser process: |
| 43 | |
| 44 | * **CC Category**: The CC category contains all resource allocations used in |
| 45 | the Chrome Compositor. When GPU rasterization is enabled, these resource |
| 46 | allocations will be GPU allocations as well. See also |
| 47 | [docs/memory-infra/probe-cc.md][cc-memory]. |
| 48 | * **Skia/gpu_resources Category**: All GPU resources used by Skia. |
| 49 | * **GPUMemoryBuffer Category**: All GPUMemoryBuffers in use in the current |
| 50 | process. |
| 51 | |
| 52 | GPU process: |
| 53 | |
| 54 | * **GPU Category**: All GPU allocations, many shared with other processes. |
| 55 | * **GPUMemoryBuffer Category**: All GPUMemoryBuffers. |
| 56 | |
| 57 | ## Example |
| 58 | |
| 59 | Many of the objects listed above are shared between multiple processes. |
| 60 | Consider a GL texture used by CC --- this texture is shared between a renderer |
Colin Blundell | 0e34e34 | 2023-07-28 08:19:31 | [diff] [blame] | 61 | and the GPU process. Additionally, the texture may be backed by a SharedImage |
| 62 | which was created from a GPUMemoryBuffer, which is also shared between the |
| 63 | renderer and GPU process. This means that the single texture may show up in the |
| 64 | memory logs of two different processes multiple times. |
hjd | 0304f11 | 2016-11-14 22:36:53 | [diff] [blame] | 65 | |
| 66 | To make things easier to understand, each GPU allocation is only ever "owned" |
| 67 | by a single process and category. For instance, in the above example, the |
| 68 | texture would be owned by the CC category of the renderer process. Each |
| 69 | allocation has (at least) two sizes recorded --- _size_ and _effective size_. |
| 70 | In the owning allocation, these two numbers will match: |
| 71 | |
| 72 | ![Matching size and effective size][owner-size] |
| 73 | |
| 74 | Note that the allocation also gives information on what other processes it is |
| 75 | shared with (seen by hovering over the green arrow). If we navigate to the |
| 76 | other allocation (in this case, gpu/gl/textures/client_25/texture_216) we will |
| 77 | see a non-owning allocation. In this allocation the size is the same, but the |
| 78 | _effective size_ is 0: |
| 79 | |
| 80 | ![Effective size of zero][non-owner-size] |
| 81 | |
Colin Blundell | 5007feef | 2023-07-20 14:57:29 | [diff] [blame] | 82 | Other types, such as GPUMemoryBuffers and SharedImages have similar sharing |
hjd | 0304f11 | 2016-11-14 22:36:53 | [diff] [blame] | 83 | patterns. |
| 84 | |
| 85 | When trying to get an overview of the absolute memory usage tied to the GPU, |
| 86 | you can look at the size column (not effective size) of just the GPU process' |
| 87 | GPU category. This will show all GPU allocations, whether or not they are owned |
| 88 | by another process. |
| 89 | |
| 90 | [cc-memory]: /docs/memory-infra/probe-cc.md |
| 91 | [owner-size]: https://storage.googleapis.com/chromium-docs.appspot.com/a325c4426422e53394a322d31b652cfa34231189 |
| 92 | [non-owner-size]: https://storage.googleapis.com/chromium-docs.appspot.com/b8cf464636940d0925f29a102e99aabb9af40b13 |