OLD | NEW |
1 # GPU Memory Tracing | 1 This document has moved to [//docs/memory-infra/probe-gpu.md](/docs/memory-infra
/probe-gpu.md). |
2 | 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]: memory_infra.md | |
15 [gpu-size-column]: https://storage.googleapis.com/chromium-docs.appspot.com/c7d6
32c18d90d99e393ad0ade929f96e7d8243fe | |
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 [cc/memory][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]: /cc/memory.md | |
92 [owner-size]: https://storage.googleapis.com/chromium-docs.appspot.com/a325c
4426422e53394a322d31b652cfa34231189 | |
93 [non-owner-size]: https://storage.googleapis.com/chromium-docs.appspot.com/b8cf4
64636940d0925f29a102e99aabb9af40b13 | |
OLD | NEW |