Re: [OA][RFC] Exposing low-resolution engine business via sysfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi,

On 12/01/2023 07:50, FlightlessMango wrote:
Hi,

I am the developer of MangoHud[1], a Vulkan and OpenGL overlay for monitoring FPS / temperatures / CPU/GPU load and more.

I would like to add support for i915 (and xe in the future) but I am currently unable to do this easily because not everything I need is exposed directly to non-root users. Namely:

  * Engine business (RCS)
  * CPU, iGPU and dGPU power usage
  * IMC bandwith (nice to have but not mandatory)

This is a problem because it would require us to ship a setuid binary to poll these metrics for the overlay (we can't run games as root).

For your information, this is Intel-specific as AMD and NVIDIA are exposing these values directly. I understand the security concerns, but we are not asking for super precise information (1% accuracy is perfect).

Can we work together on this, what are your thoughts?

A few angles here. First of all, last time you raised it I think we didn't have per client engine busyness in fdinfo. So *if* you are satisfied with reading client's own busyness you can do it unprivileged via /proc/<pid>|self/fdinfo/<fd>.

Secondly, i915 internal stats, iGPU power usage and IMC are exposed via three separate perf/PMU drivers, of which this team (this mailing) is really responsible for only i915. The access controls for all though are common and provided by the core kernel. See /proc/sys/kernel/perf_event_paranoid and corresponding docs.

Long(-ish) time ago we have proposed making the latter a per PMU driver but that did not get any traction in the kernel.

Once you move to dGPU then for power you will get to use hwmon and for that one I am currently not familiar how access control works.

And finally for the new Xe driver I not aware how it will expose it so I am copying Rodrigo in case he knows.

In summary I personally see these options for what i915 stats are concerned:

1. You go with fdinfo and get what you can.

2. We try to propose per PMU access controls once more.

And then maybe the point below becomes less controversial, unlikely though.

3. You instruct users to configure /proc/sys/kernel/perf_event_paranoid, or convince the distros to setuid your tool, or something along those lines.

Regards,

Tvrtko


Thanks for your consideration.

//Simon Hallsten

[1] https://github.com/flightlessmango/MangoHud






[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux