[PATCH] drm/amdgpu: Add sysfs file for VBIOS
Deucher, Alexander
Alexander.Deucher at amd.com
Fri Aug 25 20:06:49 UTC 2017
> -----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
More information about the amd-gfx
mailing list