Is this a new feature, an improvement, or a change to existing functionality?
New Feature
Please provide a clear description of the problem this feature solves
Binary DCGM fields (DCGM_FT_BINARY) are dropped during metric collection. toString() in gpu_collector.go only handles DCGM_FT_INT64, DCGM_FT_DOUBLE, and DCGM_FT_STRING — binary fields fall through and return FailedToConvert. This makes it impossible to export useful fields like DCGM_FI_DEV_ENC_STATS (506) and DCGM_FI_DEV_FBC_STATS (507).
Feature Description
It would be great to have support for DCGM_FT_BINARY fields. For example, DCGM_FI_DEV_ENC_STATS maps to dcgmDeviceEncStats_v1, a small struct containing sessionCount, averageFps, and averageLatency. These could be deserialized and exposed as individual Prometheus metrics. The same would apply to other binary fields like DCGM_FI_DEV_FBC_STATS.
Describe your ideal solution
A registry of deserializers for known binary structs that maps each struct member to a separate metric. For example, adding DCGM_FI_DEV_ENC_STATS to the counters CSV would produce:
DCGM_FI_DEV_ENC_STATS_SESSION_COUNT{gpu="0",...} 2
DCGM_FI_DEV_ENC_STATS_AVG_FPS{gpu="0",...} 30
DCGM_FI_DEV_ENC_STATS_AVG_LATENCY{gpu="0",...} 5
This approach would make it straightforward to add future binary fields without one-off code for each.
Additional context
No response
Is this a new feature, an improvement, or a change to existing functionality?
New Feature
Please provide a clear description of the problem this feature solves
Binary DCGM fields (DCGM_FT_BINARY) are dropped during metric collection. toString() in gpu_collector.go only handles DCGM_FT_INT64, DCGM_FT_DOUBLE, and DCGM_FT_STRING — binary fields fall through and return FailedToConvert. This makes it impossible to export useful fields like DCGM_FI_DEV_ENC_STATS (506) and DCGM_FI_DEV_FBC_STATS (507).
Feature Description
It would be great to have support for DCGM_FT_BINARY fields. For example, DCGM_FI_DEV_ENC_STATS maps to dcgmDeviceEncStats_v1, a small struct containing sessionCount, averageFps, and averageLatency. These could be deserialized and exposed as individual Prometheus metrics. The same would apply to other binary fields like DCGM_FI_DEV_FBC_STATS.
Describe your ideal solution
A registry of deserializers for known binary structs that maps each struct member to a separate metric. For example, adding DCGM_FI_DEV_ENC_STATS to the counters CSV would produce:
This approach would make it straightforward to add future binary fields without one-off code for each.
Additional context
No response