> -----Original Message----- > From: Kuehling, Felix > Sent: Friday, August 25, 2017 3:59 PM > To: Deucher, Alexander; amd-gfx at lists.freedesktop.org > Subject: Re: [PATCH] drm/amdgpu: Add sysfs file for VBIOS > > On 2017-08-25 03:40 PM, Deucher, Alexander wrote: > >> -----Original Message----- > >> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On > Behalf > >> Of Felix Kuehling > >> Sent: Friday, August 25, 2017 3:34 PM > >> To: amd-gfx at lists.freedesktop.org > >> Subject: Re: [PATCH] drm/amdgpu: Add sysfs file for VBIOS > >> > >> I think the power measurement is a bit of a hack right now. It requires > >> pinging the SMU twice to start and stop the measurement, and waiting > for > >> some time (but not too long) in between. I think if we want to expose > >> this via hwmon, we'll need to have some kind of timer that polls it in > >> regular intervals in the background and updates a value that can be > >> queried through HWMon without delay. > > I don't know that hwmon has any requirements with respect to delay. I > think a slight delay in reading it back through hwmon is preferable to a > background thread polling it. Regular polling may also have negative impacts > on performance or stability, depending on how it was validated. > > If an application is reading hwmon data from 4 GPUs and each query for > power usage from each GPU takes one second, that would seriously limit > the update frequency of the application. > > Maybe the first read could block long enough to get useful data. But > subsequent reads could probably avoid blocking if we keep track of the > time stamp of the last query. If it was very recently, we can return the > last value. If it was long enough ago, we can get an updated value from > the SMU. If the last query was too long ago, we start over and block for > a second. Could we just set the sampling period down? If the application is polling for instantaneous power we'd probably want a short smu sampling period anyway. Otherwise, the application shouldnâ??t be polling so frequently in the first place. Alex > > Regards, > Felix > > > Alex > > > >> Regards, > >> Felix > >> > >> > >> On 2017-08-25 11:56 AM, Deucher, Alexander wrote: > >>>> -----Original Message----- > >>>> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On > >> Behalf > >>>> Of Russell, Kent > >>>> Sent: Friday, August 25, 2017 9:00 AM > >>>> To: StDenis, Tom; Christian König; amd-gfx at lists.freedesktop.org > >>>> Subject: RE: [PATCH] drm/amdgpu: Add sysfs file for VBIOS > >>>> > >>>> There is GPU Power usage reported through amdgpu_pm_info, which > >> also > >>>> has some other information as well. I'd like that in sysfs, but I am > unsure if > >>>> we are allowed to due to the other information reported there. > >>> For power and voltage, I believe there are standard hwmon interfaces. > It > >> would probably be best to expose it via those. For clocks/pcie, I think you > >> can already determine them via the existing pp sysfs interfaces. > >>> Alex > >>> > >>>> Kent > >>>> > >>>> -----Original Message----- > >>>> From: StDenis, Tom > >>>> Sent: Friday, August 25, 2017 8:58 AM > >>>> To: Christian König; Russell, Kent; amd-gfx at lists.freedesktop.org > >>>> Subject: Re: [PATCH] drm/amdgpu: Add sysfs file for VBIOS > >>>> > >>>> On 25/08/17 08:56 AM, Christian König wrote: > >>>>> Hi Kent, > >>>>> > >>>>> agree on the VBIOS dump file, that clearly belongs to debugsf. > >>>>> > >>>>> The power usage stuff I can't say much about cause I'm not deeply > into > >>>>> this, but keep in mind the restriction for sysfs: > >>>>> 1. It's a stable interface. So it must be very well designed. > >>>>> 2. Only one value per file. I think the power stuff doesn't fulfill > >>>>> that requirement at the moment. > >>>> What "power" stuff are we talking about? The sensors interface or the > >>>> pm_info or something else? > >>>> > >>>> Keep in mind umr uses the sensors debugfs file in --top mode. > >>>> > >>>> Tom > >>>> _______________________________________________ > >>>> amd-gfx mailing list > >>>> amd-gfx at lists.freedesktop.org > >>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > >>> _______________________________________________ > >>> amd-gfx mailing list > >>> amd-gfx at lists.freedesktop.org > >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > >> _______________________________________________ > >> amd-gfx mailing list > >> amd-gfx at lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
