Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(137)

Unified Diff: components/tracing/docs/memory_infra_gpu.md

Issue 2494063002: Move memory docs to docs/memory-infra (Closed)
Patch Set: rebase Created 4 years, 1 month ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « components/tracing/docs/memory_infra.md ('k') | components/tracing/docs/memory_infra_startup_tracing.md » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
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
« no previous file with comments | « components/tracing/docs/memory_infra.md ('k') | components/tracing/docs/memory_infra_startup_tracing.md » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698