[Feature Request] Upstream i915 process enumeration via DRM fdinfo when legacy sysfs clients is absent

Start with clientInfoAvailableInFdInfo() in level_zero/sysman/source/shared/linux/kmd_interface/sysman_kmd_interface.h and scanProcessesState() in sysman_os_global_operations_imp.cpp, which chooses the legacy sysfs clients path and maps its failure to unsupported. The request is a design question about adding an fdinfo-based backend, so a newcomer should first confirm scope with maintainers. Done would mean an agreed design and tests for the selection logic, which the payload does not name.

Pre-submission Checklist

• I have searched for similar feature requests and found none
• This feature request includes a clear description of the proposed functionality

Search performed: #809 is related background, but the request below is specifically for the upstream-i915 fdinfo backend. The fdinfo/i915 search also found memory-accounting reports rather than an explicit upstream-i915 process-enumeration request. Please link an existing tracking item if this is already covered.

Feature Title

Upstream i915 process enumeration through DRM fdinfo without the legacy sysfs clients tree.

Feature Category

API Support

GPU Hardware

Intel Arc A380 / DG2, PCI ID 8086:56a5, using the upstream i915 kernel driver. The observed GPU is a full PCI-passthrough device, not an SR-IOV virtual function.

Operating System

Linux — Fedora 44 x86_64, kernel 7.2.9-201.fc44.

API

Level Zero — Sysman, zesDeviceProcessesGetState.

Problem Statement

On this system, process enumeration returns 0x78000003 (ZE_RESULT_ERROR_UNSUPPORTED_FEATURE). GPU discovery and a native Level Zero GPU execution example work, so unavailable process telemetry should not be interpreted as absence of a usable compute device.

Observed installed software:

• Intel compute runtime / intel-level-zero: 26.35.39758.11, Fedora RPM build.
• Level Zero loader: 1.33.1.
• Consumer: xpu-smi 2.0.1.

A read-only syscall trace of the installed consumer reaches the current i915 DRM card and fails on its legacy clients directory. The selected line below omits only the PID prefix:

openat(AT_FDCWD, "/sys/class/drm/card0/clients", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)

The same GPU exposes process metadata through DRM fdinfo. A read-only inspection with sufficient process-inspection permissions found drm-driver: i915, engine counters such as drm-engine-render in nanoseconds, and memory fields including drm-total-local0, drm-resident-local0, drm-shared-local0, and their system-memory counterparts. Values, process identities and workload details are intentionally omitted here. This does not claim that all processes can be inspected without appropriate permissions.

Current upstream source was also inspected at 8c9edf6a300911953c741a777bfa572c2eee683f: SysmanKmdInterfaceI915Upstream::clientInfoAvailableInFdInfo() still returns false. scanProcessesState() selects the legacy sysfs implementation in that case, and a failed clients-directory scan is mapped to unsupported-feature.

Proposed Solution

Please consider an upstream-i915-compatible fdinfo process-enumeration backend when the legacy clients tree is not available. The existing Sysman API could remain unchanged.

This is not a proposal to simply flip the capability flag: i915 engine names/units, memory-region names, process-inspection permissions, disappearing processes, and Sysman accounting semantics need appropriate handling. If this backend is intentionally unsupported, please document the supported i915 kernel-interface prerequisites and the intended path for this configuration.

Expected Benefits

Process-aware monitoring on distributions using upstream i915, without treating a missing legacy sysfs extension as missing compute capability or requiring an unrelated kernel-driver migration solely for monitoring.

Use Case Scenarios

A system-management client enumerates the processes using a healthy Intel GPU for resource attribution. The kernel already exposes per-process DRM metadata, but the selected Sysman backend does not use it.

Code Examples / API Design

The requested API is the existing zesDeviceProcessesGetState; no new public entry point is proposed. The syscall excerpt and fdinfo field names above describe the observed interface gap, not an implementation or a claim that every Sysman field can be derived directly.

Alternatives & Workarounds

A client can implement separate i915 fdinfo collection, duplicating backend-specific logic. Reporting process telemetry as unavailable is preferable to reporting a false empty process list, but it does not provide the missing monitoring capability. Changing kernel drivers solely to obtain process statistics is not assumed to be a supported workaround for this GPU/kernel configuration.

Priority / Importance

Medium - Nice to have enhancement

Estimated Impact

Moderate - Affects a specific subset of users

References

• Related earlier discussion: https://github.com/intel/compute-runtime/issues/809
• Current i915 capability declaration: https://github.com/intel/compute-runtime/blob/8c9edf6a300911953c741a777bfa572c2eee683f/level_zero/sysman/source/shared/linux/kmd_interface/sysman_kmd_interface.h#L241-L290
• Process backend selection and missing-clients handling: https://github.com/intel/compute-runtime/blob/8c9edf6a300911953c741a777bfa572c2eee683f/level_zero/sysman/source/api/global_operations/linux/sysman_os_global_operations_imp.cpp
• Sysman initialization guidance checked: https://github.com/intel/compute-runtime/blob/8c9edf6a300911953c741a777bfa572c2eee683f/programmers-guide/SYSMAN.md

Additional Notes

This is a feature request, not a claim that the current API promises this optional capability on this configuration. The installed Fedora runtime was exercised; the newer upstream revision above was source-inspected, not installed or benchmarked. No GPU-driver migration is proposed. Minimal technical excerpts are provided rather than full host traces containing unrelated local paths.