LogViewer for HWINFO is available !

OK, I did some more analysis (watched Gamers Nexus Video) and had a more detail look at the data:
  • a lot of categories are N/A (not available, because of BETA?)
  • in another video I saw, you can use HWiNFO to get sensor information for PresentMon (?)
  • the most important categories are (Gamers Nexus Video)
    - Frametime = log category "msBetweenPresents"
    - GPU Busy = log category "msGPUActive"
In the video they said, best is to have Frametime and GPU Busy "close together" (no waiting). So I generated an addtional (calculated) log category:
  • Frametime - GPU Busy
  • the difference value of these two categories "should be something > 0"
  • ... and we can generic a statistic of this difference

Here are the diagrams:

Screenshot2.png

@NCSGeek: your average values are
  • Frametime: 6.959 ms
  • GPU Busy: 2.693 ms
  • Frametime - GPU Busy: 4.265
  • this shows also the statistics: 90.6 % of your values are around 3.937 ms, 8.3% around 6.132 ms
  • BUT: 0.21% of your frames have a negative value of -0.452 ms -> GPU Busy > Frametime (not good)
I'm wondering why PresentMon doesn't have such a "difference value" ...


Question: Are you planning on updating GenericLogViewer with this?
As I already said: "if Intel sends me a Core i9-13900K + 500 bucks for a motherboard (or someone else will sponsor me), I will do it :cool:
 
OK, I did some more analysis (watched Gamers Nexus Video) and had a more detail look at the data:
  • a lot of categories are N/A (not available, because of BETA?)
  • in another video I saw, you can use HWiNFO to get sensor information for PresentMon (?)
  • the most important categories are (Gamers Nexus Video)
    - Frametime = log category "msBetweenPresents"
    - GPU Busy = log category "msGPUActive"
In the video they said, best is to have Frametime and GPU Busy "close together" (no waiting). So I generated an addtional (calculated) log category:
  • Frametime - GPU Busy
  • the difference value of these two categories "should be something > 0"
  • ... and we can generic a statistic of this difference

Here are the diagrams:

View attachment 9726

@NCSGeek: your average values are
  • Frametime: 6.959 ms
  • GPU Busy: 2.693 ms
  • Frametime - GPU Busy: 4.265
  • this shows also the statistics: 90.6 % of your values are around 3.937 ms, 8.3% around 6.132 ms
  • BUT: 0.21% of your frames have a negative value of -0.452 ms -> GPU Busy > Frametime (not good)
I'm wondering why PresentMon doesn't have such a "difference value" ...


Question: Are you planning on updating GenericLogViewer with this?
As I already said: "if Intel sends me a Core i9-13900K + 500 bucks for a motherboard (or someone else will sponsor me), I will do it :cool:
Oh okay I didn't realize that part was in answer to my question about adding it. If he adds this metric to H@Info64 then would your tool retroactively support it?

As for my log I sent and it's values, I wouldn't look too hard into it. it was a brief capture while playing Vampire Survivors (which is a very very lightweight game) so the data may not be very valuable.
 
Here are some personal thoughts on PresentMon from Intel: I don't think the new metric called "GPU Busy" is a game changer. Why:
  • it logs an extremely large amount of data, example file contains
    - 73 different log categories with each
    - 144 data records per second (so really each frame = FPS)
  • there is so much data being processed, that this processing itself probably has an impact on the performance and possibly generates a bottleneck itself
  • especially if this data is displayed in a live overlay over the game

The tool is supposed to show whether the CPU and GPU have the same performance class and fit together perfectly. In my opinion, however, this is not the typical use case. You start with a PC build, then a few years later you usually upgrade with a better graphics card, because since a few years CPU power has always been cheaper than GPU power. The fact that individual components can be upgraded is the great advantage of a PC and the reason why perfect performance matches between CPU and GPU are the exception.

Best regards
Tom
 
Hi LannTheSmart,

that's not so easy, reading text or numbers from a file depends a lot on your own Microsoft Windows culture/language settings. E.g. some countries use a dot for decimal numbers, some use commas. The same with "special characters", they can be total different. I think for Chinese you need anyway an Unicode Codepage (?), I use the common Windows Codepage 1252, which shows the often used temperature sign correct: °.

Some tipps:
  • in selfie mode (like your screenshot) you can edit the header by yourself: just click in the topline and change it (the line with "...7945HX3D") !
  • the categories names seem to be fine, only the units within [..] are crap. Maybe you can edit them direct in the HWiNFO logfile (?)
  • Attention: Generic Log Viewer uses the category names and units from the end of the file (if available), not from the first line
I will not change the used Codepage, because then for sure other problems will occur ...

Sorry and regards
Tom
 
HWiNFO outputs the CSV in ANSI format, so the interpretation depends on the system locale used for Non-Unicode programs setting in Windows.
Another solution would be to introduce a new CSV format with UTF-8 encoding. But I don't think that CSV supports specification of encoding used so it might be problematic for GenericLogViewer to recognize the format used.
 
I'm still waiting on some feedback from Intel regarding the GPU Busy parameter clarification as this isn't directly provided by the open-source PresentMon.
And I'm also a bit worried about what @TomWoB already stated - that the monitor outputs a huge amount of data that could have a negative impact on performance.
 
Hi Martin,

as I already said above, in Gamers Nexus video it looks like
  • Frametime = log category "msBetweenPresents"
  • GPU Busy = log category "msGPUActive"
These two log categories exist in @NCSGeek's sample log file. Aren't they part of the open-source PresentMon or an available SDK ?
 
Ah, I can see that the open-source PresentMon was updated just 2 days ago and added the msGPUActive parameter :)
 
@TomWoB Separately, I have a minor bug report to make. After I take a screenshot using the screenshot button, it does not re-enable the "Show files" checkbox.

Let me know if this is not the place to bring this up though.
 
Hi,

I have been using HWiNFO and the GenericLogViewer for many years. However, the LogViewer has stopped working for me for a few years now, across several versions (both programs).

Attached is a CSV log and a PNG screenshot of the hwinfo sensor values over a period of five minutes, during which I played a game today.

The values in the GenericLogViewer mostly do not even remotely match the sensor values. I don't know whether this is due to hwinfo or the viewer and when it started to be displayed incorrectly (as I said, it's been like this for a few years).

Is the problem now known and fixed or would someone like to take care of it? I don't want to just install the latest hwinfo version because it always takes so much work to rearrange the sensor overview, and because the problem persisted with the last versions that I've tried again and again over the last few years .
 

Attachments

  • test.zip
    30.8 KB · Views: 3
Hi,

I have been using HWiNFO and the GenericLogViewer for many years. However, the LogViewer has stopped working for me for a few years now, across several versions (both programs).

Attached is a CSV log and a PNG screenshot of the hwinfo sensor values over a period of five minutes, during which I played a game today.

The values in the GenericLogViewer mostly do not even remotely match the sensor values. I don't know whether this is due to hwinfo or the viewer and when it started to be displayed incorrectly (as I said, it's been like this for a few years).

Is the problem now known and fixed or would someone like to take care of it? I don't want to just install the latest hwinfo version because it always takes so much work to rearrange the sensor overview, and because the problem persisted with the last versions that I've tried again and again over the last few years .

Problem is the use of comma "," as decimal separator which collides with the same CSV separator (also comma).
 
Thank you. That helped. But the viewer is still confused with the RAM and V-RAM values.
 

Attachments

  • test2.zip
    128.7 KB · Views: 5
Thank you. That helped. But the viewer is still confused with the RAM and V-RAM values.
The viewer will read any recorded field by HWINFO.
Eliminate your confusion, by setting up HWINFO, so this to exclude recording of non critical parameters.
HWINFO can save sensors configuration to a file (backup of settings).

Spent time to learn of how to use and configure HWINFO.

NON ENG operating systems, they need to be configured due Keyboard panel -> Settings.
 
Back
Top