[Mesa-dev] GPU (and system) monitoring

Mon Nov 20 23:02:31 UTC 2017

On Mon, Nov 20, 2017 at 5:10 PM, Dieter Nützel <Dieter at nuetzel-hh.de> wrote:
> Am 20.11.2017 18:17, schrieb Alex Deucher:
>>
>> On Mon, Nov 20, 2017 at 7:25 AM, Nicolai Hähnle <nhaehnle at gmail.com>
>> wrote:
>>>
>>> This kind of system-level monitoring is typically the domain of the
>>> kernel,
>>> not Mesa.
>>>
>>> I know you can get GPU clocks and temperature from there (e.g. umr does
>>> that
>>> for the amdgpu kernel module), I don't know about power consumption
>>> though.
>>
>>
>> Temperature and fan info are exposed via standard hwmon interfaces.
>> Clocks, temp, fan, gpu load, and power usage are exposed via a custom
>> debugfs interface.
>> umr uses that interface.
>
>
> [CC dri-devel ???]
>
> fan info is brocken (for Polaris at least) with
>
> amd-staging-drm-next
> drm-next-4.15-dc (-wip)
> linux.git since DC merge
>
> after the below commit.
> I have to send a bug report, finally...
>
> SOURCE/amd-staging-drm-next> git bisect good
> 0944c350c8eddf4064e7abb881dd245032fdfa23 is the first bad commit
> commit 0944c350c8eddf4064e7abb881dd245032fdfa23
> Author: Rex Zhu <Rex.Zhu at amd.com>
> Date:   Mon Sep 25 18:51:50 2017 +0800
>
>     drm/amdgpu: delete pp_enable in adev
>
>     amdgpu not care powerplay or dpm is enabled.
>     just check ip functions and pp functions
>
>     Change-Id: Iaac75d45170ef9b20e212465f837eaaa798365bd
>     Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
>     Signed-off-by: Rex Zhu <Rex.Zhu at amd.com>
>
> :040000 040000 72361654709479890586e383ec73088e535a1cf5
> 2b6d5a75ffc3b6fd48c63e79bf28faddcc734918 M drivers

I'm aware your issue and actually just sent a patch to fix it, but
your issue is not really relevant to this discussion and there is no
need to hijack this thread to discuss it.

Alex

>
> Greetings,
> Dieter
>
>
>
>
>> Alex
>>
>>>
>>> Cheers,
>>> Nicolai
>>>
>>>
>>>
>>> On 20.11.2017 00:08, Gordon Haverland wrote:
>>>>
>>>>
>>>> Greetings.  I've been lurking a long time.
>>>>
>>>> There is perhaps too much introduction here.
>>>>
>>>> Why I've been lurking was related to OpenCL (and btrfs) issues related
>>>> to some upgrading of hardware and software I have on my LAN when time
>>>> permitted.  Well, winter arrived and now there isn't quite so much
>>>> stuff keeping me away from the computer.
>>>>
>>>> In the near future I will have 5 computers attached to 4 UPS, two of
>>>> which will have Corsair digital power supplies.  One computer will have
>>>> a sort of deprecated AMD GPU, and the others will have newer hardware
>>>> (mostly Polaris GPUs from AMD).  Processors are all AMD.
>>>>
>>>> UPS software (NUT or proprietary) can provide estimates of how much
>>>> power the UPS are providing.  Lmsensors seems to have an ability to
>>>> read GPU temperatures as well as CPU temperatures.  SMART may give
>>>> access to disk data, I am initially thinking that SSD aren't going to
>>>> provide anything useful.  And the Gnome libgtop2 library can provide
>>>> access to CPU type process data.  There is some code out there to get
>>>> at data from Corsair digital power supplies.
>>>>
>>>> Some UPS software is sampling every 2 seconds, some every 15 or 30
>>>> seconds.  What I am looking to do, is to sample a bunch of things at
>>>> about the same rate and log it (on one machine).  Sample the
>>>> temperatures, sample the power levels and then look through the process
>>>> statistics to find the N processes that are using more than 10% of any
>>>> CPU (core).
>>>>
>>>> Much of what I am doing now, is public BOINC projects.  And these BOINC
>>>> projects may be interested in this from an energy budget point of
>>>> view.  I have some projects in mind, which a person might be able to do
>>>> from a BOINC server.  And I would like to be able to measure the energy
>>>> budget on this.
>>>>
>>>> Einstein at Home seems to be one of the few BOINC projects which produces
>>>> jobs for which Mesa3D is the OpenCL provider.  I see SETI at Home sending
>>>> jobs occasionally, but they don't compile as they assume
>>>> Catalyst/fglrx because I have AMD GPUs.
>>>>
>>>> Maybe places like SETI at Home would be inclined to create OpenCL jobs, if
>>>> there was software to measure energy budget?  One could hope.
>>>>
>>>> At the moment, I am working in Perl.  For getting at Corsair digital
>>>> power supply data, spawning some program via the shell and capturing
>>>> output should work for a start, but I probably should try to make a
>>>> library and do things via XS.  GTop has a Perl wrapper at CPAN, I don't
>>>> think I've seen a Perl wrapper around anything lmsensors related.
>>>>
>>>> Too much introduction, I apologise.
>>>>
>>>> Are there aspects of GPU use; that Mesa3D provides, should provide or
>>>> could provide?  Especially with respect to OpenCL.  Are there
>>>> places/references where I can learn about this?  No paywalled stuff
>>>> please, I have no budget.
>>>>
>>>> If this means writing code (Mesa3D seems to be mostly C, I can do that,
>>>> but most of my programming is number crunching in FORTRAN) to submit to
>>>> Mesa3D, I can do that.
>>>>
>>>> Other things I should know?
>>>>
>>>> If I get something working, github is best place to put this?  I think
>>>> it might be useful at some point.
>>>>
>>>> Have a great day!
>>>> Gord
>>>>
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>>
>>>
>>>
>>> --
>>> Lerne, wie die Welt wirklich ist,
>>> Aber vergiss niemals, wie sie sein sollte.
>>>
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev