On Mon, Feb 6, 2023 at 5:48 PM sfrcorne <sfrco...@protonmail.com> wrote:
>
> Dear Alex,
>
> First of all, thank you for your response. Personally, I use a Ryzen 5 7600X 
> however people with a Ryzen 9 7900X are also reporting this issue. The 
> relevant bug report in Mangohud can be found here: 
> "https://github.com/flightlessmango/MangoHud/issues/868";.
>
> I looked around a bit in both the Mangohud source code and the Linux kernel 
> source code.
>
> (Mangohud source): From what I understand, Mangohud looks for a file 
> "/sys/class/drm/card*/device/gpu_metrics". If this file exists (and it does 
> exists on my machine), it tries to read this file and extract the relevant 
> GPU data (and in case of an APU also the CPU data) from it (these are the 
> values I was talking about in my previous mail). When the file 
> "/sys/class/drm/card*/device/gpu_metrics" exists, it will not use the data 
> provided by hwmon (/sys/class/hwmon/hwmon*/*).
>
> (Linux kernel): The gpu_metrics file contains different data, depending on 
> what version is used. All valid versions can be found in the source code: 
> "https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/include/kgd_pp_interface.h#L725";.
>  For my CPU/APU the 'gpu_metrics_v2_1' structure is used (I tested this by 
> reading the gpu_metrics file myself). Furthermore, I think that for my case, 
> this structure is set by the function 
> "https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_5_ppt.c#L459";
>  but I am not completely sure about this.

The metrics provided by the SMU firmware varies from asic to asic.
For things that are not supported by the metrics table for a
particular asic, those fields would be 0.  You can see what metrics
are supported for your asic in smu_v13_0_5_get_gpu_metrics() as that
function populates the supported fields from the firmware to the
common structure.  current_gfxclk is not supported in your asic, but
average_gfxclk_frequency is.  So you'd want to use whichever field is
available for a particular asic in Mangohud.

>
> Lastly, I am not familiar with umr. I assume that you are referring to 
> "https://gitlab.freedesktop.org/tomstdenis/umr";? If I find some time this 
> weekend, then I will look into this some more.

Yes, that is the right link.  umr uses the same interface as mangohud,
so you should see the same data.

Alex


>
> Kind regards,
> sfrcorne
>
> ------- Original Message -------
> On Monday, February 6th, 2023 at 22:22, Alex Deucher <alexdeuc...@gmail.com> 
> wrote:
>
> > On Mon, Feb 6, 2023 at 9:22 AM sfrcorne sfrco...@protonmail.com wrote:
> >
> > > Hello,
> > >
> > > I hope this is the correct place to ask my question. I was not sure if I 
> > > should have opened a new issue on Gitlab or send an email here, since I 
> > > don't know know whether this is a bug or intended behaviour.
> > >
> > > The question is about the new AMD Ryzen 7000 CPU's. These new CPU's have 
> > > an iGPU and consequently provide a gpu_metrics file for monitoring the 
> > > GPU/CPU (APU?). This file is used by programs like Mangohud, that try to 
> > > read (among other values) the following 4 values:
> > > - current_gfxclk
> > > - current_uclk
> > > - average_cpu_power
> > > - temperature_core
> > > However it appears that on AMD Ryzen 7000 CPU's these 4 values are not 
> > > provided/updated in the gpu_metrics file. Other values like 
> > > 'average_core_power', 'temperature_l3' and the other 'current_<x>clk' are 
> > > also not provided/updated but these are not used by Mangohud at the 
> > > moment.
> > >
> > > Is this intentional or a bug? And will this be fix and/or will support 
> > > for these 4 values be added in the future?
> >
> >
> > What specific CPU/APU is this? I don't recall off hand how mangohud
> > queries this stuff, but you can take a look at the hwmon interfaces
> > exposed by the driver or if you want the whole metrics table, you can
> > use umr to fetch and decode it via the kernel interface. That will
> > allow you to verify that the firmware is producing the proper data.
> >
> > Alex

Reply via email to