drm-usage-stats.rst 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133
  1. .. _drm-client-usage-stats:
  2. ======================
  3. DRM client usage stats
  4. ======================
  5. DRM drivers can choose to export partly standardised text output via the
  6. `fops->show_fdinfo()` as part of the driver specific file operations registered
  7. in the `struct drm_driver` object registered with the DRM core.
  8. One purpose of this output is to enable writing as generic as practicaly
  9. feasible `top(1)` like userspace monitoring tools.
  10. Given the differences between various DRM drivers the specification of the
  11. output is split between common and driver specific parts. Having said that,
  12. wherever possible effort should still be made to standardise as much as
  13. possible.
  14. File format specification
  15. =========================
  16. - File shall contain one key value pair per one line of text.
  17. - Colon character (`:`) must be used to delimit keys and values.
  18. - All keys shall be prefixed with `drm-`.
  19. - Whitespace between the delimiter and first non-whitespace character shall be
  20. ignored when parsing.
  21. - Neither keys or values are allowed to contain whitespace characters.
  22. - Numerical key value pairs can end with optional unit string.
  23. - Data type of the value is fixed as defined in the specification.
  24. Key types
  25. ---------
  26. 1. Mandatory, fully standardised.
  27. 2. Optional, fully standardised.
  28. 3. Driver specific.
  29. Data types
  30. ----------
  31. - <uint> - Unsigned integer without defining the maximum value.
  32. - <str> - String excluding any above defined reserved characters or whitespace.
  33. Mandatory fully standardised keys
  34. ---------------------------------
  35. - drm-driver: <str>
  36. String shall contain the name this driver registered as via the respective
  37. `struct drm_driver` data structure.
  38. Optional fully standardised keys
  39. --------------------------------
  40. - drm-pdev: <aaaa:bb.cc.d>
  41. For PCI devices this should contain the PCI slot address of the device in
  42. question.
  43. - drm-client-id: <uint>
  44. Unique value relating to the open DRM file descriptor used to distinguish
  45. duplicated and shared file descriptors. Conceptually the value should map 1:1
  46. to the in kernel representation of `struct drm_file` instances.
  47. Uniqueness of the value shall be either globally unique, or unique within the
  48. scope of each device, in which case `drm-pdev` shall be present as well.
  49. Userspace should make sure to not double account any usage statistics by using
  50. the above described criteria in order to associate data to individual clients.
  51. - drm-engine-<str>: <uint> ns
  52. GPUs usually contain multiple execution engines. Each shall be given a stable
  53. and unique name (str), with possible values documented in the driver specific
  54. documentation.
  55. Value shall be in specified time units which the respective GPU engine spent
  56. busy executing workloads belonging to this client.
  57. Values are not required to be constantly monotonic if it makes the driver
  58. implementation easier, but are required to catch up with the previously reported
  59. larger value within a reasonable period. Upon observing a value lower than what
  60. was previously read, userspace is expected to stay with that larger previous
  61. value until a monotonic update is seen.
  62. - drm-engine-capacity-<str>: <uint>
  63. Engine identifier string must be the same as the one specified in the
  64. drm-engine-<str> tag and shall contain a greater than zero number in case the
  65. exported engine corresponds to a group of identical hardware engines.
  66. In the absence of this tag parser shall assume capacity of one. Zero capacity
  67. is not allowed.
  68. - drm-memory-<str>: <uint> [KiB|MiB]
  69. Each possible memory type which can be used to store buffer objects by the
  70. GPU in question shall be given a stable and unique name to be returned as the
  71. string here.
  72. Value shall reflect the amount of storage currently consumed by the buffer
  73. object belong to this client, in the respective memory region.
  74. Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
  75. indicating kibi- or mebi-bytes.
  76. - drm-cycles-<str> <uint>
  77. Engine identifier string must be the same as the one specified in the
  78. drm-engine-<str> tag and shall contain the number of busy cycles for the given
  79. engine.
  80. Values are not required to be constantly monotonic if it makes the driver
  81. implementation easier, but are required to catch up with the previously reported
  82. larger value within a reasonable period. Upon observing a value lower than what
  83. was previously read, userspace is expected to stay with that larger previous
  84. value until a monotonic update is seen.
  85. - drm-maxfreq-<str> <uint> [Hz|MHz|KHz]
  86. Engine identifier string must be the same as the one specified in the
  87. drm-engine-<str> tag and shall contain the maximum frequency for the given
  88. engine. Taken together with drm-cycles-<str>, this can be used to calculate
  89. percentage utilization of the engine, whereas drm-engine-<str> only reflects
  90. time active without considering what frequency the engine is operating as a
  91. percentage of it's maximum frequency.
  92. ===============================
  93. Driver specific implementations
  94. ===============================
  95. :ref:`i915-usage-stats`