Index: components/tracing/docs/memory_infra_gpu.md |
diff --git a/components/tracing/docs/memory_infra_gpu.md b/components/tracing/docs/memory_infra_gpu.md |
index 57f49a48d54691cbd0cf104610504330b9154678..799ba7cecc2b683ff723343fbe6e7801d45a6a91 100644 |
--- a/components/tracing/docs/memory_infra_gpu.md |
+++ b/components/tracing/docs/memory_infra_gpu.md |
@@ -1,93 +1,2 @@ |
-# GPU Memory Tracing |
+This document has moved to [//docs/memory-infra/probe-gpu.md](/docs/memory-infra/probe-gpu.md). |
-This is an overview of the GPU column in [MemoryInfra][memory-infra]. |
- |
-[TOC] |
- |
-## Quick Start |
- |
-If you want an overview of total GPU memory usage, select the GPU process' GPU |
-category and look at the _size_ column. (Not _effective size_.) |
- |
-![Look at the size column for total GPU memory][gpu-size-column] |
- |
-[memory-infra]: memory_infra.md |
-[gpu-size-column]: https://storage.googleapis.com/chromium-docs.appspot.com/c7d632c18d90d99e393ad0ade929f96e7d8243fe |
- |
-## In Depth |
- |
-GPU Memory in Chrome involves several different types of allocations. These |
-include, but are not limited to: |
- |
- * **Raw OpenGL Objects**: These objects are allocated by Chrome using the |
- OpenGL API. Chrome itself has handles to these objects, but the actual |
- backing memory may live in a variety of places (CPU side in the GPU process, |
- CPU side in the kernel, GPU side). Because most OpenGL operations occur over |
- IPC, communicating with Chrome's GPU process, these allocations are almost |
- always shared between a renderer or browser process and the GPU process. |
- * **GPU Memory Buffers**: These objects provide a chunk of writable memory |
- which can be handed off cross-process. While GPUMemoryBuffers represent a |
- platform-independent way to access this memory, they have a number of |
- possible platform-specific implementations (EGL surfaces on Linux, |
- IOSurfaces on Mac, or CPU side shared memory). Because of their cross |
- process use case, these objects will almost always be shared between a |
- renderer or browser process and the GPU process. |
- * **GLImages**: GLImages are a platform-independent abstraction around GPU |
- memory, similar to GPU Memory Buffers. In many cases, GLImages are created |
- from GPUMemoryBuffers. The primary difference is that GLImages are designed |
- to be bound to an OpenGL texture using the image extension. |
- |
-GPU Memory can be found across a number of different processes, in a few |
-different categories. |
- |
-Renderer or browser process: |
- |
- * **CC Category**: The CC category contains all resource allocations used in |
- the Chrome Compositor. When GPU rasterization is enabled, these resource |
- allocations will be GPU allocations as well. See also |
- [cc/memory][cc-memory]. |
- * **Skia/gpu_resources Category**: All GPU resources used by Skia. |
- * **GPUMemoryBuffer Category**: All GPUMemoryBuffers in use in the current |
- process. |
- |
-GPU process: |
- |
- * **GPU Category**: All GPU allocations, many shared with other processes. |
- * **GPUMemoryBuffer Category**: All GPUMemoryBuffers. |
- |
-## Example |
- |
-Many of the objects listed above are shared between multiple processes. |
-Consider a GL texture used by CC --- this texture is shared between a renderer |
-and the GPU process. Additionally, the texture may be backed by a GLImage which |
-was created from a GPUMemoryBuffer, which is also shared between the renderer |
-and GPU process. This means that the single texture may show up in the memory |
-logs of two different processes multiple times. |
- |
-To make things easier to understand, each GPU allocation is only ever "owned" |
-by a single process and category. For instance, in the above example, the |
-texture would be owned by the CC category of the renderer process. Each |
-allocation has (at least) two sizes recorded --- _size_ and _effective size_. |
-In the owning allocation, these two numbers will match: |
- |
-![Matching size and effective size][owner-size] |
- |
-Note that the allocation also gives information on what other processes it is |
-shared with (seen by hovering over the green arrow). If we navigate to the |
-other allocation (in this case, gpu/gl/textures/client_25/texture_216) we will |
-see a non-owning allocation. In this allocation the size is the same, but the |
-_effective size_ is 0: |
- |
-![Effective size of zero][non-owner-size] |
- |
-Other types, such as GPUMemoryBuffers and GLImages have similar sharing |
-patterns. |
- |
-When trying to get an overview of the absolute memory usage tied to the GPU, |
-you can look at the size column (not effective size) of just the GPU process' |
-GPU category. This will show all GPU allocations, whether or not they are owned |
-by another process. |
- |
-[cc-memory]: /cc/memory.md |
-[owner-size]: https://storage.googleapis.com/chromium-docs.appspot.com/a325c4426422e53394a322d31b652cfa34231189 |
-[non-owner-size]: https://storage.googleapis.com/chromium-docs.appspot.com/b8cf464636940d0925f29a102e99aabb9af40b13 |