gildekel@chromium.org chromeos-gfx-display@chromium.org

Modeset attempt result of an external display. Every time an external display is connected/disconnected, or when the display mode of the external screen is changed by the user, Chrome attempts to modeset the display. This metric tracks the result of those attempts. Resolution and RefreshRate metrics will be recorded for each attempt.

gildekel@chromium.org chromeos-gfx-display@chromium.org

Modeset attempt result of an internal display. This is recorded after Chrome attempted all the available modes and finally modeset the display. All the previously attempted modes and refreshes, including the successful one will be recorded.

gildekel@chromium.org chromeos-gfx-display@chromium.org

Modeset attempt result of an internal display. Chrome might try additional modes after a failed attempt. Every time an external display is connected/disconnected, or when the display mode of the external screen is changed by the user, Chrome attempts to modeset the display. This metric tracks the result of those attempts. Resolution and RefreshRate metrics will be recorded for each attempt.

gildekel@chromium.org chromeos-gfx-display@chromium.org

The final result of a configuration attempt across all displays. This is recorded every time Chrome configures all connected displays, or fails to do so after exhausting all available modes in one (or more) of the displays. Partial success occurs when a configuration is successful, but not with the requested resolution/refresh rate for one (or more) of the connected displays (e.g. a display fails to modeset at 4k@60Hz, but succeeds at 1440p@60Hz).

gildekel@chromium.org chromeos-gfx-display@chromium.org

Total number of external displays connected via MST and being configured. This is recorded every time an external display is connected/disconnected, or when the display mode of a screen is about to change.

gildekel@chromium.org chromeos-gfx-display@chromium.org

Percentage of external displays connected via MST and being configured. This is recorded every time an external display is connected/disconnected, or when the display mode of a screen is about to change.

gildekel@chromium.org chromeos-gfx-display@chromium.org

Total number of external displays being configured. This is recorded every time an external display is connected/disconnected, or when the display mode of a screen is about to change.

gildekel@chromium.org chromeos-gfx-display@chromium.org

Tracks an {Connection} display's resulting refresh rate after a successful display configuration.

gildekel@chromium.org chromeos-gfx-display@chromium.org

{Connection} {Report}

gildekel@chromium.org chromeos-gfx-display@google.com

The type of serial number retrieved from block zero of a display's EDID during EDID parsing.

gildekel@chromium.org chromeos-gfx-display@google.com

The number of serial numbers provided in an EDID (i.e. via block zero and/or the serial number descriptor block). Values should be in the range of 0-2.

gildekel@chromium.org chromeos-gfx-display@google.com

The availability (or lack thereof) of tracked optional fields during EDID parsing of external.

gildekel@chromium.org chromeos-gfx-display@google.com

Whether or not multiple connected displays produced identical display IDs due to incomplete EDIDs. This may occur when identical displays (same make and model) lack serial numbers in both the EDID's block zero or S/N descriptor block. Recorded every time Chrome OS detects a change in display configuration and attempts to get an updated list of available displays.

gildekel@chromium.org chromeos-gfx-display@google.com

Type of failure that occurs during EDID parsing. Typically the failure is caused by a mismatch between the EDID size and the expected offset of the data component.

cwallez@chromium.org

The sum of the size of the CPU-side memory allocations of Buffer11's copies (vs. GPU memory allocations). These allocations are used when modifying the buffer data on the CPU or when transfering to GPU memory via DMA.

jonahr@google.com angle-team@google.com

An extended Windows error code returned from D3D11CreateDevice on error when ANGLE's D3D backend is in use. Can be almost any valid HRESULT or DXGI error code, which are listed at https://msdn.microsoft.com/en-us/library/windows/desktop/bb509553.aspx.

jonahr@google.com angle-team@google.com

The maxmium supported (or currently requested) Direct3D feature level in D3D11 ANGLE. We support as low as 9.3, and as high as 11.1, though Chrome should only use 10.0+ for D3D11. Gives an indication of how new a user's video card is, what features it supports, and it's general speed tier. Recorded on D3D device initialization, loss, or reset when ANGLE's D3D backend is in use.

jonahr@google.com angle-team@google.com

The result from initializing a D3D11 device in ANGLE. Can be success, or one of several error codes which indicate different reasons for failing. Recorded on D3D11 device initialization when ANGLE's D3D backend is in use.

jonahr@google.com angle-team@google.com

The result from initializing a D3D9 device in ANGLE. Can be success, or one of several error codes which indicate different reasons for failing. Recorded on D3D9 device initialization when ANGLE's D3D backend is in use.

geofflang@chromium.org angle-team@google.com

The size of compiled D3D shader bytecode.

geofflang@chromium.org angle-team@google.com

The time it takes for fxc to compile HLSL to D3D bytecode. Recorded for all clients regardless of support for high resolution timers.

sky@chromium.org angle-team@google.com

An integer that is logged shortly after the gpu process starts up. The value is the number of shaders that were needed and were available in the shader cache.

sky@chromium.org angle-team@google.com

An integer that is logged shortly after the gpu process starts up. The value is the number of shaders that were needed and were not in the shader cache.

geofflang@chromium.org angle-team@google.com

The time it takes for the Metal driver to compile a shader with the newLibraryFromSource function. Recorded for all clients regardless of support for high resolution timers.

sky@chromium.org angle-team@google.com

A boolean that is logged for each shader program. A value of true means the metallib for the shader existed in blob-cache. A value of false means the metallib for the shader did not exist in blob-cache.

jonahr@google.com angle-team@google.com

Windows computers running Windows 8+, or running Windows 7 with a platform update, support the newer version of DXGI. This update also indicates the computer is capable of running Direct3D 11.1 if the hardware supports it. Recorded on D3D11 device initialization when ANGLE's D3D backend is in use.

blundell@chromium.org geofflang@chromium.org vasilyt@chromium.org angle-team@google.com

Tracks the amount of time that it took for WebView to save HWUI's GL state when using ANGLE (when not using ANGLE, the corresponding interval is recorded as Android.WebView.Gfx.SaveHWUIStateNonANGLEMicroseconds; the method of recording is not quite identical, but the two metrics should be comparable at a high level). Recorded once per saving of HWUI state when drawing with GL. Recorded for all clients as ANGLE does not support checking for high-resolution clocks (in practice, all Android devices have high-resolution clocks).

zmo@chromium.org spvw@chromium.org chrome-catan@google.com

Records whether AppHelp.dll is loaded at GPU initialization. Only recorded on Windows platform at GPU process launch time. It is not yet known what exactly is triggering the load of AppHelp.dll, and so we can't be sure that AppHelp.dll won't be loaded after this is collected, even if this metric is false. A bug tracking metric collection related to the application compatibility layer can be found at crbug.com/1357617. Part of a performance investigation that Catan is doing into GPU startup time.

vmiura@chromium.org graphics-dev@chromium.org

Counts number of browser invocations for which a GPU feature is allowed/blocklisted/disabled.

vmiura@chromium.org graphics-dev@chromium.org

Counts number of browser invocations for which the GPU process is blocked due to a blocklist entry match.

vasilyt@chromium.org nazabris@microsoft.com jochin@microsoft.com

Records, during GPU process initialization, the combination of the following two features being enabled/disabled: 1) Accelerated 2D Canvas 2) OOP Rasterization of Canvas.

kylechar@chromium.org

Records what compositing mode (software, GL, etc.) Chrome is using every five minutes. This is the default compositing mode that most windows will use. There are some window types (eg. menus on some platforms) that always use software compositing and ignore the default.

sievers@chromium.org

The reason a GPU command buffer context of a given type was lost.

vmiura@chromium.org

Whether D3D11 supports B8G8R8A8 format for render targets.

vmiura@chromium.org

Whether D3D11 supports B8G8R8A8 format for 2D textures.

zmo@chromium.org graphics-dev@chromium.org

Records the highest D3D_FEATURE_LEVEL available, collected in the info collection GPU process, once per UMA ping. This is Windows platform only.

magchen@chromium.org zmo@chromium.org

The maximum D3D12 feature level supported in the gpu drivers. It is recorded in the browser process 120 seconds after the browser launch.

magchen@chromium.org zmo@chromium.org amaiorano@google.com

The maximum supported D3D shader model version on a D3D12 device. It is recorded in the browser process 120 seconds after the browser launch. Note that the "2" suffix was added when a fix was made in how this stat is collected: the previous unsuffixed version would store "unknown/unsupported" on systems that supported shader model 5.1 to 6.5, but were unaware of 6.6. The suffixed version correctly stores the highest supported shader model.

jonahr@google.com angle-team@google.com

ANGLE's currently active D3D shader model version. Logged once every startup of the GPU process, on Windows only. Note that Shader Models 2 and 3 map to D3D9 with ANGLE, and 4+ map to D3D11 ANGLE.

sunnyps@chromium.org zmo@chromium.org

If the system approves a swap chain's custom present duration request, this is the approved custom present duration. If the swap chain's custom present duration request is not approved, this is zero.

sunnyps@chromium.org graphics-dev@chromium.org

How the Desktop Window Manager presented Chrome's DirectComposition layers of video or canvas elements to the screen. Only recorded on Windows. NOTE: This metric was expired and not collecting data between 2021-12-31 and crrev.com/c/4041850 (M110).

magchen@chromium.org zmo@chromium.org graphics-dev@chromium.org

HRESULT return value of IDXGIFactory2::CreateSwapChainForComposition.

magchen@chromium.org zmo@chromium.org

The number of YUV overlays we are going to present in each frame if the number is not 0. Recorded when the overlay processor is called for drawing a frame.

sunnyps@chromium.org zmo@chromium.org

Recorded for each stream video quad (on overlay processing) the reason it was or wasn't put in an overlay.

sunnyps@chromium.org zmo@chromium.org

Recorded for each texture quad (on overlay processing) the reason it was or wasn't put in an overlay. (This metric might be lack of coverage between 2022-05-01 and 2022-06-24 due to metric expiration.)

magchen@chromium.org zmo@chromium.org

Recorded for each quad (on overlay processing) with protected video type the reason it was or wasn't put in an overlay.

magchen@chromium.org zmo@chromium.org graphics-dev@chromium.org

HRESULT return value of IDCompositionDevice2::CreateSurface.

magchen@chromium.org graphics-dev@chromium.org

True if the GPU driver supports hardware overlays. Recorded during Chrome GPU initialization and each time the overlay caps change.

magchen@chromium.org zmo@chromium.org

Recorded for each video quad during the video playback whether it is an underlay or an overlay.

sunnyps@chromium.org zmo@chromium.org

Number of presented frames for which presentation queries haven't completed. Recorded on each vblank.

sunnyps@chromium.org zmo@chromium.org magchen@chromium.org

Which overlay format was chosen for YUV overlays. Recorded once per GPU process launch only if hardware overlays are supported. (Might be lack of metrics coverage between 2022-05-01 and 2022-06-24 due to metric expiration.)

sunnyps@chromium.org zmo@chromium.org magchen@chromium.org

True if Chrome will try to use DirectComposition overlays. (Might be lack of metrics coverage between 2021-10-04 and 2022-06-24 due to metric expiration.)

magchen@chromium.org zmo@chromium.org

Whether creating swap chain for protected video succeeded. Recorded once per swap chain creation.

sunnyps@chromium.org zmo@chromium.org magchen@chromium.org

What format was used for each overlay swap chain on each swap buffers. (Might be lack of metrics coverage between 2020-12-31 and 2022-06-24 due to metric expiration.)

sunnyps@chromium.org zmo@chromium.org magchen@chromium.org

What code path was used to present a video frame. Recorded on each present. (Might be lack of metrics coverage between 2022-03-06 and 2022-06-24 due to metric expiration.)

vmiura@chromium.org kbr@chromium.org zmo@chromium.org

For every entry in the gpu driver bug list that is hit on a machine, this records the id. Entry 0 is the total number of times that data is recorded. It should be recorded whenever new GPU information is received: on startup, whenever a GPU process launches, and whenever the active GPU changes.

zmo@chromium.org graphics-dev@chromium.org

The display type used to ask for an EGLDisplay.

alemate@chromium.org magchen@chromium.org oshima@chromium.org

Records the duration of EnsureWorkVisible GPU call. Since it's blocking UI thread we want to measure it, and this histogram must be active as long as this call is still blocking. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution.

alemate@chromium.org magchen@chromium.org oshima@chromium.org

Records the duration of EnsureWorkVisible GPU call. Since it's blocking UI thread we want to measure it, and this histogram must be active as long as this call is still blocking. This is a sister histogram to GPU.EnsureWorkVisibleDuration. The former is our target goal. However it's custom buckets do not have enough granularity to measure improvement steps. This metric will instead cap at 5s, and allow the buckets to give us better visibility into the 15ms-250ms interval ranges. We will use this one until we improve the blocking call.

cduvall@chromium.org jam@chromium.org

Measures the time it takes to synchronously establish the GPU channel. Logged every time a sync call to EstableGpuChannelSync is made and a channel is not already available.

ccameron@chromium.org graphics-dev@chromium.org

The time that elapsed between a call to glCreateProgram and the call to query GL_LINK_STATUS via glGetProgramiv in Skia's GrGLInterface. This encompasses the creation of the vertex, fragment, and geometry shaders, their compilation, and their linking. This is called for every program created by Skia via the GrGLInterface.

magchen@chromium.org zmo@chromium.org

Records the OpenGL implementation mode. Recorded during GPU process initilization.

zmo@chromium.org graphics-dev@chromium.org

The number of GPUs a device has, excluding software renderers. Recorded when GPU process launches and sends GPUInfo to browser process.

Deprecated 2023-06. The metric is replaced by GPU.GPUInitializationTime.V4 which is fixing the too small UMA buckets of the V3 metric. magchen@chromium.org zmo@chromium.org

The time between the GPU process starts and the GPU Info is collected at GPU process startup and recorded in browser process when this piece info is sent back to browser process. The range is between 5ms and 5s.

magchen@chromium.org zmo@chromium.org graphics-dev@chromium.org

The time between the GPU process start and the collection of GPU info during the process's startup phase. The time range is between 5ms and 90s. Emitted after the collection of GPU info. Reported for all clients. This metric is similar to GPU.GPUInitializationTime.V3, but there are two main differences. First, the range for GPU.GPUInitializationTime.V4 is capped at 90s while the range of the other metric is capped at 5s. Second, this metric is emitted earlier in the execution because this metric is recorded at the same time as trace events which require the timestamp marking the start and end of the GPU initialization to be in scope, whereas V3 only requires the time spent.

zmo@chromium.org graphics-dev@chromium.org

Counts for the exit codes returned by the GPU process when it terminated.

vmiura@chromium.org

Whether the GPU process successfully initialized or failed and then exitted normally.

vmiura@chromium.org

Startup time of the GPU process as measured by the GPU process host.

jonross@chromium.org msisov@igalia.com graphics-dev@chromium.org

The reason a GPU process is terminated. It works only when TERMINATION_STATUS_PROCESS_WAS_KILLED TerminationStatus is set. The goal of this histogram is to get spikes of the above mentioned case when Ozone/Wayland terminates the GPU process due to invalid data it received if any. NOTE: this metric was expired from 2019-08-14 to 2022-11-30 and was brought back by crrev.com/c/4040947.

vmiura@chromium.org

Counts for each time the GPU Process Host detects the process dies.

zmo@chromium.org graphics-dev@chromium.org

Records if GPU hardware acceleration is explicitly disabled by the user. Recorded when the browser process launches. Warning: this histogram was expired from 2022-01-30 to 2022-04-29; data may be missing.

zmo@chromium.org graphics-dev@chromium.org

Records whether the system has a discrete GPU, collected in the info collection GPU process, once per UMA ping. This is Windows platform only. Warning: this histogram was expired from 2020-04-24 to 2022-04-29; data may be missing.

jonahr@google.com angle-team@google.com

The time that the GPU process spends in initializing the GL surface, and collecting graphics information. Records times up to three minutes.

zmo@chromium.org graphics-dev@chromium.org

Records the highest Intel GPU generation of the system using the GPU info collected at GPU process startup time, once per UMA ping.

sunnyps@chromium.org zmo@chromium.org

Records user device's GPU series type. Only recorded on Windows platform at GPU process launch time. Only meaningful with Intel GPUs.

magchen@chromium.org ccameron@chromium.org

The time that it took to update the CALayer tree and commit the transaction. This is often affected by IOSurface paging. This metric is only collected on Mac, which only has high-resolution clocks.

ccameron@chromium.org

The time that it took for a call to IOSurfaceCreate to complete.

ccameron@chromium.org

The time that it took for a call to glFlush to complete. This is often affected by IOSurface paging.

magchen@chromium.org ccameron@chromium.org

The time that the GPU's main CPU thread spends waiting for previous frames' GPU work to complete. Recorded at every frame. This metric is only collected on Mac, which only has high-resolution clocks.

senorblanco@chromium.org

The maximum number of multisampled anti-aliasing (MSAA) samples per pixel that the user's GPU can render.

cduvall@chromium.org swarm-team@google.com

The GPU memory reported by the system as the "szDisplayMemoryEnglish" property from DxDiagnostics. This is only reported on Windows after a 2 minute delay after startup.

cwallez@chromium.org graphics-dev@chromium.org

Read-write textures are not always supported on Metal. This histograms is meant to gather information so that the WebGPU W3C group can decide whether to require support for this feature. The reported tier is the best tier that was found on the system. Meaning that if only one of the GPUs support read-write textures, a non-zero tier will be reported. The histogram is recorded at GPU process startup time.

ccameron@chromium.org graphics-dev@chromium.org

Compiling a MTLLibrary will sometimes hang forever. When initializing the gpu process, a test shader is compiled to see if the MTLCompilerService is responding or not. This records the time that it took for the compile to succeeded, up to 1 minute. After 1 minute, a timeout sentinel value of 3 minutes is reported.

ccameron@chromium.org graphics-dev@chromium.org

Linking a MTLRenderPipelineState will sometimes hang forever. When initializing the GPU process, a test shader is compiled to see if the MTLCompilerService is responding or not. This records the time that it took for the compile to succeeded, up to 1 minute. After 1 minute, a timeout sentinel value of 3 minutes is reported.

sky@chromium.org angle-team@google.com

The amount of time (in microseconds) the gpu process takes to load the metal shader lib cache. Logged after loading completes on a background thread.

sky@chromium.org angle-team@google.com

The number of shader programs in the metal shader lib cache. Logged after loading of the metal shader lib cache completes.

sky@chromium.org angle-team@google.com

The amount of time (in microseconds) the gpu process main thread is blocked waiting for the metal shader lib cache to load.

zmo@chromium.org graphics-dev@chromium.org

AMD device IDs from multi-gpu devices. Recorded when GPU process launches and sends GPUInfo to browser process.

zmo@chromium.org graphics-dev@chromium.org

Nvidia device IDs from multi-gpu devices. Recorded when GPU process launches and sends GPUInfo to browser process.

jonross@chromium.org chrome-gpu-metrics@google.com

Time delta between swaps, when there are multiple successful swaps in the same vsync. The delta is reported as a percentage of vsync interval. This can be recorded every time we present a frame.

magchen@chromium.org zmo@chromium.org graphics-dev@chromium.org

Records HRESULT when setting the video processor stream extension for Nvidia {Extension} to {State}. This metric is recorded every frame when processing video streams in DirectComposition.

khushalsagar@chromium.org penghuang@chromium.org

During OutOfProcess(Oop) raster, the renderer generates and sends the requisite glyph data for rasterizing a tile with the serialized paint commands. If the data for any glyph is missing, the GPU process attempts to use a fallback glyph from the cache. This records each time we encounter a cache miss on the GPU and whether we could use a fallback.

hubbe@chromium.org cassew@chromium.org media-dev-uma@chromium.org

Records if any connected monitor is HDR capable. Recorded when the gpu process starts. Only recorded on Windows as of M-61. If monitor enumeration fails, this metric will not be provided.

magchen@chromium.org ccameron@chromium.org

The time that the GPU's main CPU thread spends producing pending CALayer tree on Mac. Recorded when Skia output surface schedules overlays at every frame. This metric is only collected on Mac, which only has high-resolution clocks.

junov@chromium.org graphics-dev@chromium.org

Records the reason why the deserialization of a PaintOp failed. Recorded in PaintOpReader::Read* methods when the decoding a paint op fails. These failures are typically caused by an invalid or unexpected state or invalid serialized data.

jonahr@google.com angle-team@google.com

The time we spend in GLES2DecoderPassthroughImpl::DoLinkProgram. Related to how much time we spend compiling shaders during startup. Expired in June 2022, and revived in M106. Data may be incomplete for the period during which the histogram was expired.

vmiura@chromium.org

Recorded once for every GPU process launch and crash when GPU process is started for hardware accelerated GPU compositing and/or WebGL. Crash buckets are based on crash count for disabling features. With OOP-D enabled the display compositor also runs in the GPU process.

vmiura@chromium.org

Recorded once for every GPU process launch and crash when GPU process is started for SwiftShader WebGL. Crash buckets are based on crash count for disabling features. With OOP-D enabled the display compositor with software compositing will also run as part of the GPU process.

jonahr@google.com angle-team@google.com

If a successfully linked program was found in the GPU program cache during a program link call. Expired in June 2022, and revived in M106. Data may be incomplete for the period during which the histogram was expired.

vmiura@chromium.org

The time to check the program cache that we've already compiled the shader. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution.

vmiura@chromium.org

The time to compile a shader. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution.

sky@chromium.org graphics-dev@chromium.org

Time it takes for RasterDecoderImpl::FlushSurfaces() to complete. Recorded for the first 100 flushes.

penghuang@chromium.org graphics-dev@chromium.org

log2() of MSAA sample count of a raster task. Value is in [log2(1),log2(64)] or [0,6] range. If log2() of the MSAA sample count is 0 (MSAA sample count is 1), it means MSAA is disabled.

spvw@chromium.org chrome-catan@google.com

Records whether report only mode is enabled at GPU process watchdog hang time. Currently, we are not seeing any of the hangs/crashes reported by report-only mode, despite the experiment rolling out. General Catan investigation: https://crbug.com/1350257 Report only feature: https://crbug.com/1356196 Part of a performance investigation that Catan is doing into GPU startup time.

berlu@chromium.org chrome-gpu-metrics@google.com

Records the wall time taken spent by each GPU scheduler task waiting on it's dependencies to resolve. The time delta starts when the waiting fence is added and finishes when the last fence is removed. Only recorded for clients with high resolution clocks.

berlu@chromium.org chrome-gpu-metrics@google.com

Records the wall time taken spent by each GPU scheduler task waiting on to be scheduled once all its dependencies have been resolved. The time delta starts when the last waiting fence is passed and stops when the tasks starts running. If the schedulers is working properly, for a high priority task, this metric should be minimal. Only recorded for clients with high resolution clocks.

berlu@chromium.org chrome-gpu-metrics@google.com

Records the wall time taken between calls to schedule the task run and the actual run of the task. Ideally this should always be as close to 0 as possible. Only recorded for clients with high resolution clocks.

vmiura@chromium.org

Counts activation and deactivation of accelerated compositing.

kylechar@chromium.org chrome-gpu-metrics@google.com

Records the type of each SharedImageBacking that's initialized/registered.

penghuang@chromium.org graphics-dev@chromium.org

Whether or not the content of a SharedImage is consumed. False indicates the content of a SharedImage is never used due to destroying the SharedImage or writing new content to it before using it.

vasilyt@chromium.org hitawala@chromium.org

Tracks which formats can be supported for creating SharedImages with real GpuMemoryBuffers on Ozone based platforms. Result is an enum that represents multiplanar buffer formats in order of possible support eg. NV12, YV12 and whether they can be used on platform that supports native pixmaps. This is logged once per gpu process launch.

hitawala@chromium.org vasilyt@chromium.org

Tracks the multiplanar format used for creating shared image with GpuMemoryBuffers. Result is a bool that checks if the format is a new multiplanar shared image format or legacy multiplanar buffer format. This is logged once per CreateSharedImage with GpuMemoryBuffer call.

hitawala@chromium.org graphics-dev@chromium.org

Tracks if shared images are created with hardware GpuMemoryBuffers of RG88 format on Ozone based platforms. Result is a bool that reports if RG88 format is supported for creating shared images with hardware GMBs. This is logged once per gpu process launch.

zmo@chromium.org graphics-dev@chromium.org

Collects whether Chrome uses software renderer or hardware GPU 20 seconds after Chrome starts, and records this value once per UMA ping. This value is not re-collected at each recording time because GPU process could crash for various reasons and fall back to software rendering. This value is intended to reflect device capabilities rather than the current state.

vmiura@chromium.org

Records whether a client was selected for the Stage3D on XP field trial or not.

magchen@chromium.org zmo@chromium.org

This metric shows whether the GPU supports D3D12. It is recorded in the browser process 120 seconds after the browser launch.

vasilyt@chromium.org backer@chromium.org

This is logged once per frame if the output surface provides timing information. It measures the time of SwapBuffers call. Only reported when there is single surface swap in the same vsync interval. Only reported for platforms supporting high resolution clocks.

boliu@chromium.org graphics-dev@chromium.org

Whether a transfer cache entry is found when trying to retrieve it. Recorded on every transfer cache look up.

boliu@chromium.org graphics-dev@chromium.org

When a transfer cache is found, record max historical time between reuses. Recorded on every successful transfer cache look up.

boliu@chromium.org graphics-dev@chromium.org

When a transfer cache entry is deleted, record how many times it was used. Recorded when an entry is deleted.

boliu@chromium.org graphics-dev@chromium.org

When a transfer cache is found, record the time since last use. Recorded on every successful transfer cache look up.

boliu@chromium.org graphics-dev@chromium.org

When a transfer cache entry is deleted, record the last time the entry was used. Recorded when an entry is deleted.

magchen@chromium.org zmo@chromium.org graphics-dev@chromium.org

Records HRESULT for VideoProcessorBlt. This metric is recorded when processing a video stream in DirectComposition with {Extension} {State}.

vikassoni@chromium.org penghuang@chromium.org vasilyt@chromium.org

Whether the extension VK_EXT_memory_budget is supported or not. Recorded once during every gpu process initialization.

backer@chromium.org penghuang@chromium.org vasilyt@chromium.org

Shows if we had a vkPipelineCache entry in cache when skia requested it. Recorded each time skia loads vkPipelineCache entry from the GrShaderCache.

backer@chromium.org penghuang@chromium.org vasilyt@chromium.org

Shows if the populated from disk cache entry was used by skia or discarded and why. Recorded when cache entry that was read from disk is either loaded by skia, overwriten by skia or discarded by GrShaderCache.

backer@chromium.org penghuang@chromium.org vasilyt@chromium.org

Size of stored VkPipelineCache in kb. Recorded every time we store a pipeline cache item. Currently happens when gpu goes idle after we stored or loaded new shader.

backer@chromium.org penghuang@chromium.org vasilyt@chromium.org

Duration of storeVkPipelineCacheData in Skia, this includes chromium side GrShaderCache::store. Recorded even if data didn't fit into the cache. Only reported for platforms supporting high resolution clocks.

penghuang@chromium.org vasilyt@chromium.org graphics-dev@chromium.org

Duration of vkCreateGraphicsPipelines call. Recorded every time Skia creates graphics pipeline. Only reported for platforms supporting high resolution clocks.

stanisc@chromium.org

Whether WaitForVBlank operation has been successful or failed with one of the errors prompting a backup delay based v-sync mechanism. Recorded each time a new GPU v-sync signal is generated.

magchen@chromium.org zmo@chromium.org graphics-dev@chromium.org

Recorded for each time the GPU watchdog thread starts, crashes and ends.

magchen@chromium.org zmo@chromium.org graphics-dev@chromium.org

Recorded timeout events when the GPU watchdog enters OnWatchdogTimeout.

geofflang@chromium.org graphics-dev@chromium.org

Types of EGL displays used to back WebGL contexts. Recorded at context creation time in the GPU process.

geofflang@chromium.org graphics-dev@chromium.org

Types of EGL displays used to back large (area >= 128*128) WebGL contexts. Recorded at context creation time in the GPU process.

enga@chromium.org mdb.webgpu-dev-team@google.com

Tracks whether a call to Create{Module} was successful, excluding when the result is found in frontend cache.

enga@chromium.org mdb.webgpu-dev-team@google.com

Tracks the amount of time in microseconds it takes for a call to Create{Module} to complete, excluding when the result is found in frontend cache. Recorded only for clients that support high-resolution clocks.

cduvall@chromium.org mdb.webgpu-dev-team@google.com

Records whether WebGPU has any GPU adapters available. This is recorded during GPU process startup.

cduvall@chromium.org mdb.webgpu-dev-team@google.com

Records the maximum storage buffer binding size if {AdapterType} GPU is available. This is recorded during GPU process startup.

cduvall@chromium.org mdb.webgpu-dev-team@google.com

Records the maximum 2D texture dimensions if {AdapterType} GPU is available. This is recorded during GPU process startup.

cwallez@google.com enga@google.com kainino@google.com

WebGPU support level. Recorded on GPU info collection a couple minutes after browser startup. Compatibility mode support means that WebGPU is supported on a non-core backend like OpenGLES. Core backends can always support compatibility mode so compat-on-core-adapter is not reported in this metric. Supported means at least one adapter of that type was available. Blocklisted means all adapters of that type were blocklisted. None means that no adapters of that type were available. Software adapters are considered as None in this metric.

lokokung@google.com mdb.webgpu-dev-team@google.com

Tracks the amount of time in microseconds it takes for a cached call to {Cacheable} to complete without error when we have a cache hit. This includes the load time from the cache and time to deserialize the result. Recorded only for clients that support high-resolution clocks.

lokokung@google.com mdb.webgpu-dev-team@google.com

Tracks the amount of time in microseconds it takes for a cached call to {Cacheable} to complete without error when we have a cache miss. This includes the time necessary to create the results of {Cacheable} from scratch, but does not include the time taken to write the results back into the cache. Recorded only for clients that support high-resolution clocks.

vmiura@chromium.org

Counts of context initialization that succeed or fail based on combinations of attributes requiring canRecoverFromContextLoss and devices that report can_lose_context. Failing Init is desired when a device can not guarantee it won't fail for a user that can not handle failures, e.g. DX9 on WinXP used by Canvas2D'

vmiura@chromium.org

The WinSAT (Windows System Assessment Tool) gaming graphics score. It is in the range 1.0-5.9 on Vista, 1.0-7.9 on Win7 and 1.0-9.9 on Win8. 0 represents a failure to get the score. This is collected each time Chrome is launched.

vmiura@chromium.org

The WinSAT (Windows System Assessment Tool) gaming graphics score, scaled by 10x. It is in the range 10-59 on Vista, 10-79 on Win7 and 10-99 on Win8. 0 represents a failure to get the score. This is collected each time Chrome is launched.

vmiura@chromium.org

The WinSAT (Windows System Assessment Tool) graphics score. It is in the range 1.0-5.9 on Vista, 1.0-7.9 on Win7 and 1.0-9.9 on Win8. 0 represents a failure to get the score. This is collected each time Chrome is launched.

vmiura@chromium.org

The WinSAT (Windows System Assessment Tool) graphics score, scaled by 10x. It is in the range 10-59 on Vista, 10-79 on Win7 and 10-99 on Win8. 0 represents a failure to get the score. This is collected each time Chrome is launched.

vmiura@chromium.org

A boolean representing whether or not we succeeded in getting the system's WinSAT scores. This is collected each time Chrome is launched.

vmiura@chromium.org

The WinSAT (Windows System Assessment Tool) overall system score. This is the minimum of all the individual subscores. It is in the range 1.0-5.9 on Vista, 1.0-7.9 on Win7 and 1.0-9.9 on Win8. 0 represents a failure to get the score. This is collected each time Chrome is launched.

vmiura@chromium.org

The WinSAT (Windows System Assessment Tool) overall system score, scaled by 10x. This is the minimum of all the individual subscores. It is in the range 10-59 on Vista, 10-79 on Win7 and 10-99 on Win8. 0 represents a failure to get the score. This is collected each time Chrome is launched.

vmiura@chromium.org

The amount of time it takes to read the WinSAT results. This is collected each time Chrome is launched. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution.

magchen@chromium.org ccameron@chromium.org graphics-dev@chromium.org

The average time delta between the expected BeginFrame time and the actual time of BeginFrame on Mac. Each recorded number is an average result of 3600 frames. It's recorded every 3600 frames when OnBeginFrame or OnTimerTick is called. This metric is only for Mac clients with high-resolution clocks.

petermcneeley@chromium.org graphics-dev@chromium.org

An enum status result for attempted delegated compositing (success or failure reason) recorded every drawn frame. Currently only recorded for LaCros delegated compositing.

petermcneeley@chromium.org khaslett@chromium.org graphics-dev@chromium.org

A count of the number of proposed overlay candidates available for overlay selection. Recorded every time a frame is rendered by the display compositor.

petermcneeley@chromium.org khaslett@chromium.org graphics-dev@chromium.org

Quad material for current promoted overlay, per frame. Recorded every time a frame is rendered by the display compositor.

khaslett@chromium.org kylechar@chromium.org graphics-dev@chromium.org

Overlay strategies used to promote Hardware Overlays, once or more per frame. Recorded every time a frame is rendered by the display compositor, or once per overlay promoted if multiple were promoted.

petermcneeley@chromium.org khaslett@chromium.org graphics-dev@chromium.org

The time, in milliseconds, since the change in overlay selection. Recorded every time a frame is rendered by the display compositor.

magchen@chromium.org zmo@chromium.org

Any root damage excluding overlay damage in the current frame?

magchen@chromium.org zmo@chromium.org

The root damage type excluding underlay damage in the current frame.

magchen@chromium.org ccameron@chromium.org graphics-dev@chromium.org

The result of creating CVDisplaylink in ExternalBeginFrameSourceMac. If successful, BeginFrameSource is driven by HW VSync instead of timer. This histogram does not include the data from DelayBasedBeginFrameSourceMac. It's recorded each time a DisplayLink is created during RootCompositorFrameSinkImpl/ExternalBeginFrameSourceMac creation or during the monitor change in the existing ExternalBeginFrameSourceMac.

petermcneeley@chromium.org graphics-dev@chromium.org

Time spent computing the number of active File Descriptors. This is logged once every 5 minutes as the cost of this computation is estimated to be at least 1ms. Currently only recorded for LaCros delegated compositing. Warning: This metric does not include reports from clients with low-resolution clocks.

petermcneeley@chromium.org graphics-dev@chromium.org

{FdStat} File Descriptors for the GPU process. This is logged once every 5 minutes as the cost of this computation is estimated to be at least 1ms. Currently only recorded for LaCros delegated compositing.

sashamcintosh@chromium.org chromeos-gfx@chromium.org

The time that a begin frame is throttled due to max pending swaps. Recorded when draw and swap executes (only when a frame is throttled). Refer to BeginFrameSource::SetIsGpuBusy for details. Warning: This metric does not include reports from clients with low-resolution clocks.