1.. _drm-client-usage-stats: 2 3====================== 4DRM client usage stats 5====================== 6 7DRM drivers can choose to export partly standardised text output via the 8`fops->show_fdinfo()` as part of the driver specific file operations registered 9in the `struct drm_driver` object registered with the DRM core. 10 11One purpose of this output is to enable writing as generic as practically 12feasible `top(1)` like userspace monitoring tools. 13 14Given the differences between various DRM drivers the specification of the 15output is split between common and driver specific parts. Having said that, 16wherever possible effort should still be made to standardise as much as 17possible. 18 19File format specification 20========================= 21 22- File shall contain one key value pair per one line of text. 23- Colon character (`:`) must be used to delimit keys and values. 24- All keys shall be prefixed with `drm-`. 25- Whitespace between the delimiter and first non-whitespace character shall be 26 ignored when parsing. 27- Keys are not allowed to contain whitespace characters. 28- Numerical key value pairs can end with optional unit string. 29- Data type of the value is fixed as defined in the specification. 30 31Key types 32--------- 33 341. Mandatory, fully standardised. 352. Optional, fully standardised. 363. Driver specific. 37 38Data types 39---------- 40 41- <uint> - Unsigned integer without defining the maximum value. 42- <keystr> - String excluding any above defined reserved characters or whitespace. 43- <valstr> - String. 44 45Mandatory fully standardised keys 46--------------------------------- 47 48- drm-driver: <valstr> 49 50String shall contain the name this driver registered as via the respective 51`struct drm_driver` data structure. 52 53Optional fully standardised keys 54-------------------------------- 55 56Identification 57^^^^^^^^^^^^^^ 58 59- drm-pdev: <aaaa:bb.cc.d> 60 61For PCI devices this should contain the PCI slot address of the device in 62question. 63 64- drm-client-id: <uint> 65 66Unique value relating to the open DRM file descriptor used to distinguish 67duplicated and shared file descriptors. Conceptually the value should map 1:1 68to the in kernel representation of `struct drm_file` instances. 69 70Uniqueness of the value shall be either globally unique, or unique within the 71scope of each device, in which case `drm-pdev` shall be present as well. 72 73Userspace should make sure to not double account any usage statistics by using 74the above described criteria in order to associate data to individual clients. 75 76- drm-client-name: <valstr> 77 78String optionally set by userspace using DRM_IOCTL_SET_CLIENT_NAME. 79 80 81Utilization 82^^^^^^^^^^^ 83 84- drm-engine-<keystr>: <uint> ns 85 86GPUs usually contain multiple execution engines. Each shall be given a stable 87and unique name (keystr), with possible values documented in the driver specific 88documentation. 89 90Value shall be in specified time units which the respective GPU engine spent 91busy executing workloads belonging to this client. 92 93Values are not required to be constantly monotonic if it makes the driver 94implementation easier, but are required to catch up with the previously reported 95larger value within a reasonable period. Upon observing a value lower than what 96was previously read, userspace is expected to stay with that larger previous 97value until a monotonic update is seen. 98 99- drm-engine-capacity-<keystr>: <uint> 100 101Engine identifier string must be the same as the one specified in the 102drm-engine-<keystr> tag and shall contain a greater than zero number in case the 103exported engine corresponds to a group of identical hardware engines. 104 105In the absence of this tag parser shall assume capacity of one. Zero capacity 106is not allowed. 107 108- drm-cycles-<keystr>: <uint> 109 110Engine identifier string must be the same as the one specified in the 111drm-engine-<keystr> tag and shall contain the number of busy cycles for the given 112engine. 113 114Values are not required to be constantly monotonic if it makes the driver 115implementation easier, but are required to catch up with the previously reported 116larger value within a reasonable period. Upon observing a value lower than what 117was previously read, userspace is expected to stay with that larger previous 118value until a monotonic update is seen. 119 120- drm-total-cycles-<keystr>: <uint> 121 122Engine identifier string must be the same as the one specified in the 123drm-cycles-<keystr> tag and shall contain the total number cycles for the given 124engine. 125 126This is a timestamp in GPU unspecified unit that matches the update rate 127of drm-cycles-<keystr>. For drivers that implement this interface, the engine 128utilization can be calculated entirely on the GPU clock domain, without 129considering the CPU sleep time between 2 samples. 130 131A driver may implement either this key or drm-maxfreq-<keystr>, but not both. 132 133- drm-maxfreq-<keystr>: <uint> [Hz|MHz|KHz] 134 135Engine identifier string must be the same as the one specified in the 136drm-engine-<keystr> tag and shall contain the maximum frequency for the given 137engine. Taken together with drm-cycles-<keystr>, this can be used to calculate 138percentage utilization of the engine, whereas drm-engine-<keystr> only reflects 139time active without considering what frequency the engine is operating as a 140percentage of its maximum frequency. 141 142A driver may implement either this key or drm-total-cycles-<keystr>, but not 143both. 144 145Memory 146^^^^^^ 147 148- drm-memory-<region>: <uint> [KiB|MiB] 149 150Each possible memory type which can be used to store buffer objects by the 151GPU in question shall be given a stable and unique name to be returned as the 152string here. 153 154The region name "memory" is reserved to refer to normal system memory. 155 156Value shall reflect the amount of storage currently consumed by the buffer 157objects belong to this client, in the respective memory region. 158 159Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' 160indicating kibi- or mebi-bytes. 161 162This key is deprecated and is an alias for drm-resident-<region>. Only one of 163the two should be present in the output. 164 165- drm-shared-<region>: <uint> [KiB|MiB] 166 167The total size of buffers that are shared with another file (e.g., have more 168than a single handle). 169 170- drm-total-<region>: <uint> [KiB|MiB] 171 172The total size of all created buffers including shared and private memory. The 173backing store for the buffers does not have to be currently instantiated to be 174counted under this category. 175 176- drm-resident-<region>: <uint> [KiB|MiB] 177 178The total size of buffers that are resident (have their backing store present or 179instantiated) in the specified region. 180 181This is an alias for drm-memory-<region> and only one of the two should be 182present in the output. 183 184- drm-purgeable-<region>: <uint> [KiB|MiB] 185 186The total size of buffers that are purgeable. 187 188For example drivers which implement a form of 'madvise' like functionality can 189here count buffers which have instantiated backing store, but have been marked 190with an equivalent of MADV_DONTNEED. 191 192- drm-active-<region>: <uint> [KiB|MiB] 193 194The total size of buffers that are active on one or more engines. 195 196One practical example of this can be presence of unsignaled fences in an GEM 197buffer reservation object. Therefore the active category is a subset of 198resident. 199 200Implementation Details 201====================== 202 203Drivers should use drm_show_fdinfo() in their `struct file_operations`, and 204implement &drm_driver.show_fdinfo if they wish to provide any stats which 205are not provided by drm_show_fdinfo(). But even driver specific stats should 206be documented above and where possible, aligned with other drivers. 207 208Driver specific implementations 209------------------------------- 210 211* :ref:`i915-usage-stats` 212* :ref:`panfrost-usage-stats` 213* :ref:`panthor-usage-stats` 214* :ref:`xe-usage-stats` 215