[Intel-gfx] [OA][RFC] Exposing low-resolution engine business via sysfs

[Intel-gfx] [OA][RFC] Exposing low-resolution engine business via sysfs

[FlightlessMango]

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?

Thanks for your consideration.

//Simon Hallsten

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

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

[Tvrtko Ursulin]

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
> 
> 
>