ClockBlocker (profiled AMD power-management control)

f65818ccdc298ab14de19768220d39594c602baf /BETA/ClockBlocker 1.2-6 BETA Rel-3.zip

-A critical deadlock has been found that mandated an immediate fix (where the ADL helper and ClockBlocker controller process lock eachother up). As both processes are multithreaded, and as this doesn't effect all threads, the programs simply appear to stop responding but cannot be terminated from Task-Manager due to elevated privileges (only applies to Windows 7 on the process termination bit).

Link in prior post will be removed and rel-1 has been taken down.


Update:

-Looking like the 64bit release build in there is hanging on close if splashscreen is shown (on one of my machines). 32bit builds aren't effected.

---Fixed, Rel-3 released.

 

ClockBlocker_HelperModule.exe always runs in Realtime priority which stutters the behavior in Audio and gaming which is very bad..... can you just change the priority to normal?

 

I cannot just change the priority to "normal" for that process as explained earlier in the thread. It runs elevated as a workaround for high CPU-load situations in games (specifically to be above the game, and anything else the system is doing). If the helper process does not get CPU-time --- [gets delayed], such as if a game is hammering every CPU core during a loading screen (low GPU load & high CPU load) ... timer events get missed.

If events are delayed and that helper does not get to execute in-time, then the video drivers assert that the workload has 'stopped'. Aka, clocks fall to idle levels. (which defeats the purpose)


Is there any reason that you can't use the ADL method?

--I do notice that your signature says you're running an E-450, which I'll admit is something that I don't have experience with (at all). On my systems there is no stuttering caused by the compute approach, but again the ADL runs at normal process priority (as it's not time critical).


EDIT: (To be a bit more clear what I mean exactly, rather than just saying to use ADL)

=> What I'm proposing is to check the checkbox highlighted in the red-recticle.


There's two helper processes in ClockBlocker, and the program itself is divided in to three components. The selected Blocking Method determines which helper is launched and kept resident during blocking.



-- Choices 1, 2, and 4 will load "ClockBlocker_HelperModule.exe" (as this module contains the CL and DC approaches). Choosing the third will not launch it.

The separation of ADL, CL, and DC permits the core process (the GUI and process scanner) to remain clean (as in, not touching a GPU itself) -- which has stability benefits through driver crashes. (among other things)

 

is it okay to use the ClockBlocker.exe or ClockBlocker_x64.exe to run without the ClockBlocker_HelperModule.exe? will it prevent to downclock without the ClockBlocker_HelperModule.exe?

 

Yes, please see the clarification I just tacked on the end of that post. (apparently thought to do that the same time as your reply)

^ this should answer that behavior wise.


EDIT: **But again, I will have to stress that I have no experience with the E-450. Which, it looks like that GPU you have listed may be the integrated graphics of.

It's unlikely that locking of clock speeds would be much help in the case of an IGP.

 

yes its and Integrated garbage GPU made by AMD and Thanks to you it Runs Smoothly now... Here's The video I recorded using the clockblocker: https://www.youtube.com/watch?v=Pvo5UDpylmI&t=597s

 

Awesome -- glad that wound up working, and hey they're not garbage persay. They may not have that much performance, but those APU's are extremely cost efficient.


-I do have to say that's actually pretty impressive. The game looks actually playable considering you have the performance hit of recording ontop of that. I honestly didn't expect even that level of gameplay due to a quick look at Notebookcheck.com.

 

As of 1.2-6 BETA Rel-4 onward, each release is to be considered a release-candidate.
(features are now frozen -- meaning it's now just bug-hunting)


*1.2-6 will be pushed out as an automatic update w/ installer in the next few days*

dad9f8aa68789271afc0393b03e516653798953d /BETA/ClockBlocker 1.2-6 BETA Rel-4.zip

And some teaser shots for those who will opt to wait for this to be tested a bit more.

Code:

===============================================================
Settings > General
===============================================================
Start With Windows = TRUE
Check for Updates on Startup = FALSE
Always Ontop = TRUE
Show Splash = FALSE
Exclude ScreenSavers (fullscreen & 3D detection) = TRUE
Disable Editor Confirmation = TRUE
Window Fade Speed = FAST
Blocking Method = ADL
Enable custom clocks = TRUE
Core-Clock = 300
Mem-Clock = 500


===============================================================
Settings > [ADL] Selected GPU's
===============================================================
AMD RADEON (TM) R9 FURY SERIES


===============================================================
Settings > Rules
===============================================================
[Executable]         | [Action]                     | [Core]    | [Mem]     | [Priority] | [Enabled]
++++++++++++++++++++ | ++++++++++++++++++++++++++++ | +++++++++ | +++++++++ | ++++++++++ | +++++++++
"skulltag.exe"       | "Block if in the foreground" | "500"     | "DEFAULT" | "0"        | "YES"    
"FULLSCREEN_PROGRAM" | "Block"                      | "1050"    | "DEFAULT" | "0"        | "YES"    
"3D_PROGRAM"         | "Block"                      | "DEFAULT" | "DEFAULT" | "0"        | "NO"     
"DEFAULT"            | "Downclock"                  | "DEFAULT" | "DEFAULT" | "0"        | "YES"  

And what will this all do profile wise?

-If Skulltag (an oldschool Doom Engine) is running and in the foreground, lock clockspeeds to 500/500 (core, mem).
-If a fullscreen app is otherwise running, set clocks to 1050/500.
-If the DEFAULT rule is active (nothing running), stop the ADL-Helper and put the card down to 300/500 before doing so.


You could achieve the same result with using "block" for the DEFAULT rule, however this would keep the ADL-Helper and WATCHDOG monitoring active. Additionally we could do something like this.

Code:

===============================================================
Settings > General
===============================================================
Core-Clock = +0
Mem-Clock = +0

===============================================================
Settings > Rules
===============================================================
[Executable]         | [Action]                     | [Core]    | [Mem]     | [Priority] | [Enabled]
++++++++++++++++++++ | ++++++++++++++++++++++++++++ | +++++++++ | +++++++++ | ++++++++++ | +++++++++
"skulltag.exe"       | "Block if in the foreground" | "500"     | "DEFAULT" | "0"        | "YES"    
"FULLSCREEN_PROGRAM" | "Block"                      | "1050"    | "DEFAULT" | "0"        | "YES"    
"3D_PROGRAM"         | "Block"                      | "DEFAULT" | "DEFAULT" | "0"        | "NO"     
"DEFAULT"            | "Block"                      | "300"     | "500"     | "0"        | "YES"    

^ The key difference is the behavior of when we close ClockBlocker, and or when the helper stops.

-In the second scenario closing ClockBlocker will reset the Fury-X back to 1050/500, with a normal clock-speed ramp.
-In the first scenario, it would remain at 300/500 even after ClockBlocker was terminated.


The reason that the first scenario works for the Fury is as 300mhz is the stock minimum core clock. Setting the default clock that low essentially clamps the defaults such that all states are 300.

 

I expect that things will be fairly straight forward due to that everything has tooltips and popups, but for a minimum description to avoid confusion.


To enable Custom clocks in profiles you need to:

-"Enable custom clocks" on Settings > General
-Choose "Use ADL-method" on Settings > General
-Move your graphics device from the left to right on Settings > "[ADL] GPU-Picker"

As always please use common sense in what clocks you apply, especially if you're adding voltage via an altered vBios or through another utility.

**Some hardware will need options such as "Extend official overclocking limits" enabled in a tool such as Afterburner (for instance for memory clock control on the R9 Fury). As this is not an overclocking tool (more of a supplement), I have not automated this process.


EDIT:
To address some more things due to emails people have been shooting me.


On "Start with Windows" not working on updates between beta releases:

-This one is not a bug. Since these are not automatic updates, if you extract the program to a new folder each time, such as:

ClockBlocker 1.2-6 BETA Rel-3\
ClockBlocker 1.2-6 BETA Rel-4\

The reason that you're finding "Start with Windows" still checked and the program not starting, is since the path has changed. ClockBlocker "does not" check the startup path, only that the correct platform type entry exists in the scheduler.

*Meaning that loading the 64bit version after loading the 32bit version (and having set auto-start) will give a warning, but loading the software from another path will NOT produce a warning.


--- Please check if this is the case before reporting a bug. Should you find the software not to start on the new version and the path still is correct in the Windows scheduler, definitely let me know of course.


On the ADL example that I provided with the Fury, and 300mhz:

If you're attempting to reproduce this please be aware that the ADL helper has to be started for clocks to be adjusted.

Or put another way: You will have to restart the program or apply a "block" rule, or else new clocks will not take effect. The ADL helper is launched one time on startup to look for and correct jammed clocks, which is why that example works between machine restarts.

 

Is this tool still needed for Fury cards?

 

If you mean for the official-fix for the "display corruption", that seems hit or miss. I know people who AMD's driver fix supposedly worked for and who never encountered a corruption after that. Yet, some of us (myself included) still have the corruption happen. Other people have different issues like display flickering, which are also clockspeed linked.

That all said, I think the majority of interest that people have in tools like this is more on the performance aspect at this point. (getting rid of clock jitter for more frametime consistency)

---Even with power-efficiency "off", clocks still go all over the place in low-load games, and you can perceive this (especially with FreeSync on).



The less-hassle and more permanent solution (for the corruption) is raising the minimum clocks from 300mhz to 500mhz with a vBios edit, coupled with a +12mv voltage bump at 500 (don't have to touch voltage at max clocks) .. or alternatively +24mv with leaving the 300mhz clock-state.


EDIT:
I think that need is a strong word and maybe the wrong one too, the more that I think about it. Yes, the problems with Fiji still exist to some degree even if AMD is working on them, or has mitigated some of them, or even if some people aren't effected. (fully come to terms with that) There's also alot of tools that can lock clocks on these cards now, raise voltage, and even vBios editors (so we have methods that are OS independent even).

-The way I see it though, the more potential workarounds that exist, the better.

 

Thanks, I don't experience any corruption anymore but do notice a black screen flicker now and then...like the driver resets to prevent the screen corruption.

Frametime boost is always welcome

Will give the tool another go. Thanks for the hard work.

 

Occasional flicker once in a while here, usually just like a less than a second little glitch.

Certainly better than it was (Where it occurred daily and lasted until you switched resolution and back again.) but probably something that isn't quite right with the GPU design although drivers have improved it. (But seem to be unable to fully solve it?)

EDIT:

Custom bios here, +24 mv now via Afterburner but it still occurs although not very frequently though it's the same even if Afterburner isn't used, GPU itself is stable though but yeah something's a bit off somewhere.

Used to be a fairly high +72 with the stock bios but now that would push it a bit above 1.3 which seems to be something of a cap for most Fury GPU's with stock PCB - All aside from the Nitro? - plus a high voltage lowers framerate far as I've read when I started looking into over volting and over clocking the GPU a bit.

Plus I'm mainly just only using it as a bit of a guarantee for extra stability though I guess raising HBM speeds might work too (But those use separate voltage that needs bios editing?) but since those have been explained as working in specific steps (AMDMatt on one of the Overclocker forums I believe it was, AMD community representative.) I'm not sure if the GPU would be able to handle that, 500mhz to 545.45 mhz and then 600 mhz and finally 666.66 mhz if I understood correctly with many GPU's managing 545 - it rounds up too if other values are specified. - but few manage 600 though outside of benchmarks it seems framerate gains from this are fairly marginal and not really worth it due to for one thing the additional heat buildup.

 

Ah, sounds like I'm both lucky and unlucky in my case.

On the latest drivers if I get the corruption it 'just-remains-there' until I cycle the monitor or change res. (just like used to be the case pre-fix) This only being the situation with my main machine (in the sig), the others just blank the display and come right back (along with clock speeds dropping when it happens).. However, I've also always been darn stable with just a core-voltage bump on this very same machine (aka, can't reproduce it with a voltage bump). No flicker or corruption while working in VS 2013 or JRPG's like Akiba's Trip.

I'd love to think this was the case of a single defective board, but I've tried many before voltage adjustment was possible, and have also RMA'd after it was as well. So yeah ... this is definitely a complex issue.

--It certainly does seem to be the case that it's either hard or near impossible to completely fix it in software, but at least one thing is for sure -- it's definitely related to power-management.


On OCing the HBM, that's not something I've much played with, or OCing in general. I'm a firm believer that performance is only valuable if you can have it WITH stability. It's easy to scoff off stability, but stability is pretty valuable even in gaming (ESPECIALLY in MMOPRG's and competitive play).


EDIT:
It's like the saying in games that a dead DPS is 0-DPS and a wipe (playing with no survivability). If you crash out of a game or lose work, I feel this is pretty well the same premise that you might as well have a potato instead of a computer.

Just not worth the risk.

 

Agreed on the stability part, I only started raising voltage as a attempt to fix GPU driver crashes in certain games and only after reading up on how well the Fury GPU could be over volted, heat buildup was also important and as a bonus I also checked in a bit on stable overclock results that I could use as a reference when testing my own GPU although it seems to have been of little actual use as it turns out with later driver releases fixed some of it and for one particular game it took a few months (Yay for stable releases? As infrequent as they seem to have become. ) but the issue was finally solved a few weeks back.
(Thankfully Win8 and newer are very stable and usually always recovers gracefully on a GPU driver crash, certain software though does not fare quite as well such as UPlay, Origin and the Battle.net client which need to be restarted afterwards or they won't work at all after such a reset heh.)

But I kept the voltage while maintaining acceptable heat buildup and what so far appears to have been a stable overclock.

Of course in my case with this GPU the Tri-X while not a custom PCB like the Nitro is still something of a cooler with a PCB and GPU under it rather than a card with a cooling unit on it or how to say, over-engineered but effective - though also heavy. - though the VRM chips or what you call them still heat up a bit although they are apparently stable up to at least 120 degrees if not higher though I'd avoid getting them that hot if possible.
(Which well some games really seem to stress the GPU so while temps above 70 are not very common some games can almost make the GPU reach 90 c after some time at which point the VRM chips would be at almost 115 degrees from what I've read.)

Still better than the 290 I had before though, stock GPU so yeah ~95c target temperature so quite a bit of heat (And the fan sounds like a hair dryer on top of that. ) anyways they had a problem with well I don't know what it was called but it's something like a gray-screen of death type crash (More common when the GPU was at load but could also occur at idle low-clock speeds.) that couldn't be recovered from and RMA was the only real way of getting a model where it didn't occur, AMD claimed to have improved it in some later driver releases but just as with the Fury disply corruption it didn't fix it for everyone.
(One RMA was all I needed and it wasn't seen after that, reading on the AMD forums and elsewhere for some it took a lot more attempts than that even for third party models where heat was less of a problem and some also used custom PCB's, I think it was rumored to be a Elpida VRAM issue as many of the stable models used Hynix unless I'm mixing the two of them up.)


EDIT: As for the Fury display corruption well the AMD thread is still ongoing so there's many more that are still affected by whatever this problem might actually be and it also varies in severity for many of the affected users from brief occasional flicker to full on display corruption.

https://community.amd.com/thread/188642

 

1.2-6 BETA Rel-4 known issues (what people are reporting):

-Race condition when run with Afterburner on startup, and using profiles in both.

If 300mhz clocks are being applied on a Fury for example, where all clocks are flattened to 300mhz (like in my provided hypothetical usage case -- not in blocking-mode), then Afterburner will fail in setting voltage on startup. (aka, won't apply a clock profile in this situation)

^ There will be a "wait for x seconds after _____ process launches" option added to deal with this.


-User login prompt reported not working for people on Win10 (for auto-start) who have symbols and or other language characters in their passwords.

^ I will simply move away from the current startup behavior and get rid of the prompt. This is causing too many problems apparently.

 

Thanks, will wait for this update.

 

**The main thing that needs testing is the new "Start with Windows" behavior. Please report in if this is working correctly, especially if you're on Windows 10. (I don't have Win10 on any test machines right now)



If you're using Afterburner and applying a profile with Afterburner and ClockBlocker on startup, it's strongly advised that you make use the new additions in this build.

-Click on "Set Wait-On"
-scroll down and select MSIAfterburner.exe
-Select "File-Name", just like you would with the profile picker for a rule edit or addition.
-Click on "Set Wait-For"
-Enter in 60 or 120 seconds. (there's no realistic reason to not pick the largest delay, as wait-for ends as soon as the process launches)
-Set Wait-After to 5-10 seconds

While you're at it, toggle "Start with Windows" and make sure the new mechanism is working. -- That's it, on the next reboot ClockBlocker should delay its startup until after Afterburner.


One last quick note on startups (per the new delay changes):

"SHIFT" will be detected at any point during ClockBlocker's startup for the duration of the startup-delay. If ClockBlocker is delayed for 30 seconds during your machine's startup, that means that entire 30-second window SHIFT cannot be held during. -I consider this the ideal way to do it for the sake of safety rather than polling once at the end, or initial start before waiting.

EDIT: Scratch that, pulling Rel-1. Bug found. (with startup behavior)

reposting after this is fixed.

 

Going to likely extend testing for another day before pushing this as an automatic update. I have a feeling there's going to be some more issues in there.


Some AV's (BitDefender AVC and Norton bloodhound on max heuristics) are flagging the loaders. I'll be submitting these (loaders shouldn't need to change again before the final release of 1.2-6), couldn't get around the problem by recompiling in different ways.

---The other processes (ClockBlocker and the helpers) seem overall to be OK in the 3 AV's that I've been running on my PC's. Probably have to move towards code-signing honestly. (this is annoying, heh)

EDIT:
^ This is speaking more of the long-term rather than going the submission route (which is slow obviously).



Far as what's next feature wise?

Well, focusing on getting 1.2-6 done first. The next thing on the TODO list is probably going to be taking another look at fullscreen detection. (for the reported games that people say it doesn't work in, or doesn't work reliably with)

-One big flaw with the current method is that it's basing its decision off client-dimensions of dialogs. It requires a single foreground dialog to span the display, which generally works I mean. However, it surely won't always work. (especially with anti-hack systems present that block windows messages)

I've come up with some more creative ways to do this (which can get around the anti-hack problems and still don't need injection). Just a matter of when I'll get the chance to play with them. These other approaches will also handle games (aka, RTS's) that rely on multiple-dialogs (such as having ingame menus be separate dialogs) ... yet still where a single application clearly covers the display. (despite the game window being out of focus in using the UI)

 

1.2-6 is released - PHEW

Thanks to everyone who tested and emailed me bug-reports during the beta testing!

Installer:
http://www.comroestudios.com/ClockBlocker/Archive/1.2/1.2-6/ClockBlocker_Setup.exe

Standalone:
http://www.comroestudios.com/ClockBlocker/Archive/1.2/1.2-6/ClockBlocker_7zExtractor.exe


Finalized release notes:

Currently going through the motions of updating everything on the site, mirror, doing the AV submissions, and making sure the auto-update process is working right.

--Hopefully we caught everything bugs wise and this goes smoothly.