[Mesa-dev] GPU (and system) monitoring

Mon Nov 20 22:10:49 UTC 2017

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

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