-
-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong GPU total memory reported #371
Comments
Thanks for the bug report! Couple of questions to help narrow in on the problem:
|
The screenshot was made with the current release version from their GitHub (v0.9.2).
|
The other |
One thing you can try is the nightly build of OhmGraphite built with LibreHardwareMonitor 0.9.2 (https://github.com/nickbabcock/OhmGraphite/suites/11729082221/artifacts/610719590)
|
The nightly build still has this issue. |
Strange, if I compile it myself and launch it in the debugger, it works fine. |
When you compile and run OhmGraphite yourself, it works!? 😨 That completely stumps me. Copied below is a bit of an investigation that I went on, but if compiling it yourself works, then it can be ignored. My best guess is that there's a difference in how LibreHardwareMonitor and OhmGraphite are refreshing sensors. OhmGraphite refreshes all hardware whenever it needs to send out new metrics. I can see that if LibreHardwareMonitor batches the refresh and UI update for each hardware component before going onto the next component, it would sidestep the possibility of a hardware sensors relying on a global value. I feel like this is partially corroborated by the fact that it is only the memory sensors that use a display handle instead of a physical handle: https://github.com/LibreHardwareMonitor/LibreHardwareMonitor/blob/6066b1a79737bb7e23217f0d2bb1b14fab04b9aa/LibreHardwareMonitorLib/Hardware/Gpu/NvidiaGpu.cs#L967 |
I wonder, if you execute:
And run the resulting zip, if that'll also show the problem. |
I've looked into it a bit more and it appears that it is related to whether the program runs as a normal process or as a service. Running it with |
Thanks for looking into it further. This issue looks like a variant of #153 (there are various possible solutions within that thread (like #153 (comment)), though the user ultimately went with the workaround in #153 (comment)). Their issue involved an AMD GPU, not Nvidia, yet seems eerily similar. |
It might be related, though it is strange that all other NVIDIA metrics appear to be working fine, it is only those 3 that are wrong. If it were some kind of permission/session thing, I would've thought either all metrics work, or none (like in the linked issue). Why only the memory metrics, and only for one GPU? Checking the "Interact with desktop" checkbox makes no difference for me. I don't really know how to investigate this further. |
Are these still problems that are persisting in 0.3x? (Issues are not closed) What are the workarounds in that case? |
I changed to run OhmGraphihte from service to "OhmGraphite run" and finally it reported GPU load percentage. (It was constantly zero when running in service mode) |
Thanks for confirming. Looks like this issue is decently widespread. I'm not sure what causes the issue or what the fix is. Now that OhmGraphite recently started targeting .net 6, it looks like there is an easy and official way to create windows services that doesn't rely on a 3rd party library: https://learn.microsoft.com/en-us/dotnet/core/extensions/windows-service?pivots=dotnet-6-0 I might poke at it and see if it's viable and fixes issues. |
Since OhmGraphite v0.31, the old windows service library has been replaced with the newer, official microsoft implementation. Let me know if this fixes the situation. |
Hi, I just noticed that OhmGraphite reports an incorrect total GPU memory size when there are multiple GPUs.
OhmGraphite's prometheus endpoint reports:
whereas the "1060 6GB" should have 6GB, as the name implies. It shows up correctly in LibreHardwareMonitor, so this does not appear to be the cause:
![image](https://private-user-images.githubusercontent.com/2377442/239679219-40a54f25-14fc-43ed-a913-3ec81c7e16ee.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjYwNzY3ODYsIm5iZiI6MTcyNjA3NjQ4NiwicGF0aCI6Ii8yMzc3NDQyLzIzOTY3OTIxOS00MGE1NGYyNS0xNGZjLTQzZWQtYTkxMy0zZWM4MWM3ZTE2ZWUucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkxMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MTFUMTc0MTI2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OGFhYTdlMGZjN2JmODY3ZjY4NmE4ZGY4YjFkNTg4NmEzZTg2Mzk5ZDRhZjE5MjczN2FjN2Q3MWYyN2VlNjYwMSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.vX-gdBR7FWirQjsZKblMYDyl093oDYbIbKECPXnTiAw)
The text was updated successfully, but these errors were encountered: