GPU Overclock offsets do not appear to save/apply with the latest G-Helper commits/previews

[schm1dtmac]

Issue: The GPU overclock offsets that I attempt to set in the UI per performance modes don't appear to save or get applied correctly as of the latest commits, despite OC application having functioned in v0.58. Even simply re-selecting the current performance mode whilst the Fans+Power window is open resets the sliders, as does closing and re-opening the Fans+Power window. The chosen clocks don't apply from what it seems, based on an oc.exe query, and don't auto-apply upon reboots/relaunches.

Steps to reproduce the behavior:

1. Go to Fans + Power
2. Adjust the frequencies for the dGPU to some non-stock value.
3. Either change performance modes, or close and reopen the window.
4. The sliders should reset back to their previous values.
5. Using another overclock utility (e.g. UXTU's oc.exe) should confirm that the system is indeed not applying the overclock set on Step 3.

Expected behaviour: The user-set overclock offsets should be applied to the dGPU, as was the case in G-Helper 0.58, and for the latest commits in particular, should also be saved out correctly per each performance mode.

Log: log.txt

System Info: ROG Strix G513QE laptop with a Ryzen 5 5600H CPU and RTX 3050 Ti GPU was used for testing under Windows 10 22H2. Armoury Crate has never been installed on this current OS install, and the unnecessary Armoury Crate Control Interface/key-popup-thing is disabled in BIOS. ASUS's System Control Interface V3 is installed and the ASUS Optimization Service is active, with other services disabled using the debloat batch provided in the readme.

[seerge]

GHelper.zip Try this build

[schm1dtmac]

G-Helper now seems to remember the clocks set per performance mode with that build, so re-selecting the current performance mode doesn't reset the shown clock values. Application of the overclock itself to the dGPU still seems to fail though when I query it with oc.exe, and the UI also resets the shown clocks still if I close and reopen the Fans + Power menu.

[seerge]

@schm1dtxbox it's probably cause app was not running as admin on that stage.

Current logic to "elevate" admin rights is

1. Each time you manually change sliders
2. Set app to run as admin on startup (if it was already scheduled to run on startup)

[schm1dtmac]

Well the weird thing is that, if I don't run G-Helper as admin with the latest builds/commits like the one sent above, it doesn't prompt me for admin when I change the sliders at all. For reference, I ran G-Helper as admin manually for all of the above testing, as I did with v0.58, where things worked as expected (and where changing the sliders without admin permissions would trigger a UAC prompt).

[seerge]

@schm1dtxbox cause in 0.58 whole logic was much more simple, it was setting clocks only after you dragged slider (now it needs to set clocks pretty much on every app launch)

Please try this build, it should do the thing

GHelper.zip

[schm1dtmac]

No dice, same behaviour as before I'm afraid with the new build sadly, regardless of whether I run as admin manually or not.

[seerge]

GHelper.zip and this ?

[schm1dtmac]

Same thing here as well.

[seerge]

can you post latest log here ?

[schm1dtmac]

log.txt Here you go

[seerge]

@schm1dtxbox can you try this build , and if still doesn't work upload a log and config again? thanks for testing GHelper.zip

[schm1dtmac]

And look at that, problem solved! When launching without admin privileges, it now asks for escalation, and when launched with escalated privileges, it auto-sets the previous OC correctly and applies any OC I set using the sliders to the dGPU properly now. Plus, overclocks are now set properly per each performance mode, which is neat.

[seerge]

ok, cool! :) i have reuploaded it over 0.59, so it's live

[schm1dtmac]

Welp, @seerge the issue's returned again as of v0.60 strangely enough. Not sure how that's happened, but it seems that the log complains about NVAPI_GPU_NOT_POWERED again at the same time too. Behaviour exhibited is the same as of just prior to you fixing it the first time (clocks reset in the UI if you exit and re-open the fans + power menu, clocks set in the UI don't seem apply to the dGPU when queried with other tools like oc.exe) log.txt

[seerge]

@schm1dtxbox does restarting app fix it?

[schm1dtmac]

Doesn't seem like it from my testing. I should also note that the app doesn't ask for admin anymore if I launch without admin privileges, despite it doing so on the fixed version of v0.59.

[seerge]

@schm1dtxbox because it asks for admin only when it needs to , and on restart since all frequencies are already set its not needed

As for not powered message, thats what gpu driver says, may be gpu is sleeping? I can’t do much from app here

[schm1dtmac]

Strange, not sure what's going on then to be honest. I wonder if it's related to the changes made regarding eco mode workarounds since that's the only thing I can think of that's changed since the fixed version of 0.59/commit that relates to the issue at hand, but I don't see anything in recent commits that's particularly concerning either.

[seerge]

@schm1dtxbox no, it's not related, that workaround will trigger only after dialog box (that you need to approve) and only if eco mode fails from first attempt

Does 0.59 keep working in same situation when 0.60 "doesn't" ?

[schm1dtmac]

Yup, 0.59 maintains functionality in the scenarios I've tested, versus 0.60 which returns to the broken behaviour.

[schm1dtmac]

Another thing by the way, after some more testing, it seems that launching 0.60 does manage to successfully re-apply the last set/previously used clocks at launch only, but doesn't show/indicate it in the UI and doesn't respond to/apply any subsequent attempts to change/reset dGPU clocks (via adjusting sliders or performance modes).

[seerge]

@schm1dtxbox GHelper.zip try this build

0.60 had logic to check current clocks, before seting new ones. and if it fails (cause gpu is sleeping) it would stop completely now it will still try to set clocks anyway as it was in 0.59

[schm1dtmac]

Manually setting clocks works now with that build (via the sliders), but the GUI still 'resets' the displayed clock to 0Mhz after closing and reopening Fans + Power, presumably due to what you said about checking current clocks failing. Switching to a performance mode that had clocks set to 0Mhz doesn't induce a change in clocks, however, switching to one that had clocks set to some other value does induce a clock change.

[seerge]

@schm1dtxbox can you post config / log here?

[schm1dtmac]

Here you go (renamed config.json to config.txt so that it'd upload to github successfully): log.txt config.txt

[seerge]

GHelper.zip Your app fails to read, but can write ... i have added a workaround for it

[schm1dtmac]

Most functionality seems to be restored now which is neat, the only things I can notice (which are likely just consequences of the workaround I assume) is that the Fans + Power window doesn't name the dGPU until after a perf mode change, and that the shown dGPU clocks are synced to what was set in the config now instead of what is applied to the dGPU currently. I actually prefer the latter change to be fair since it does reflect what was previously set/configured by the user, irrespective of whatever is set by other apps/OC utilities.

[seerge]

Cause GPU name was part of clock reading (that didn't work on your end), i have separated it GHelper.zip

[seerge]

@schm1dtxbox and in general, fact that drivers fail to report clocks, is not usual :) try to reboot laptop (and check log if it actually starts reading). Most probably it's a aftermath of disabling / enabling dGPU and nvidia driver missbehavior cause of that

[schm1dtmac]

Yeah I did make sure to reboot earlier to make sure it wasn't a fluke, but it still fails regardless, not sure why clock reading fails on 0.60 versus 0.59 when in theory nought should have changed in that regard. Haven't enabled/disabled the dGPU lately at all either so it probably isn't that. On a positive note, the new build does consistently show the GPU name now which is nice.

[seerge]

@schm1dtxbox it could fail before too, i have added error logging for reading only in 0.60. As for showing clocks, logic is

1. Show clocks from reading
2. If it failed - show clocks from config