ClockBlocker (profiled AMD power-management control)

I personally use Trixx, far better IMO and more easy UI.

--1.2.5 work's great (default) on my machine.

This tool is growing good.


@A2Razor do u suggest AB or Trixx what is more stable in your opinion?
or something else? Not only for overclock.

 

Ah, 7850, great card and probably in luck here with hardware-similarity too. Each major change I test on my Fury-X and also on an older Q6600 that I've popped a '7950' in. These are both Windows 8.1 machines that I run tests on, but hopefully you'll have success with 1.2-5's ADL changes.

-- I tried 500, 700, 850, 900, and 1100 mhz clocks from AB when I was playing around on the 7950 (with ADL blocking active).

Make sure that you set Afterburner back to official-mode, and potentially wipe drivers if needed if you see anything like clockspeed 'stacking' as mentioned in the other posts. (swapping between official and unofficial OC, you can get in to bad states like this sometime)

I'm personally fond of the interface of MSI-Afterburner, and have generally stuck with AB because before that I was a RivaTuner user. (I've always liked Alexey's software designs)

Far as what I've used AB for -- mainly software fan-control. (prefer added fan noise over letting my videocards cook) Hadn't done overclocking (on any videocards) since owning a 3dfx voodoo 3 up until the R9 Fury-X, where I was forced back in to this to properly use my card... With the Fury-X, TriXX was the first publicly released tool with some official support for voltage adjustment, and so I swapped to TriXX 5.2.1 per playing around with the Fury corruption (to add voltage). However, I never managed to have TriXX successfully apply (on any system) adjusted voltage on automatic system startup.

--If I went purely on my experience with this card, then AB works better from the auto-start standpoint. It made dealing with the corruption far easier as I was doing it manually on each start with TriXX (and often forgetting to).


Before TriXX, early versions of the project that became ClockBlocker is what I was using (as my only solution), and that was basically clamping my card at 1050mhz at all times to stop the corruption. -The Visual Studio project is actually called "AMD_NoPM" from before I had picked a proper name.

[TriXX voltage support came out not that much later after this]


Anyway, if we got down to the actual overclocking method used in TriXX.. Setting AB to Unofficial Mode "with powerplay" makes its clock adjustment on the Fury-X identical to TriXX (in terms of clockspeed traits). -So, there is no absolute advantage to one or the other here per the argument that unofficial overclock is 'better' on Powerplay7.


With ClockBlocker I'm trying to basically fill a perceived void that I see in AMD's driver CP and also to test if certain issues are the result of their clock control.

 

Just wanted to give feedback on my clock issues.
All is working now. Fixed this, as suggested by A2razor, by switching between official and unofficial mode.

Only problem i have now is that my scores have dropped in Firestrike. I actually get the same score with clocks at 1100 and 1125...weird :?

 

Great! Guessing you were seeing a dual overclock 'stacking' then, and got that all cleaned up.

Sounds like you're probably running Firestrike with the compute-method for blocking. Yes, there is indeed a very small performance penalty when at 100%-load for using that method, as this approach requires keeping a kernel active. See my response to fat4l earlier.

Keep in mind that this cost only matters and only hurts framerates if you're running a program that naturally would be at the maximum clocks w/o ClockBlocker [and pegged in load too]. (aka, a benchmarking tool or some synthetic case) Usually in realistic gaming situations the benefits (from locked clockspeeds) outweigh this tiny cost and provide a better experience.


But that said: as a workaround you can either use the ADL-method (which has absolutely zero load penalty), or add an exclusion for Firestrike (a downclock rule). Both the ADL and compute methods are pretty reliable choices at this point.

 

After enabling the hardware monitoring mode of Afterburner and testing a bit with Fallout 4 and seeing the core clock speed bouncing around between the 400 to 600 Mhz range for most of that gaming sessions I decided to finally give this tool a try, should have used it earlier because it worked really well, might help a bit with stuttering / frame latency as well I suppose or what it's called.
(Added a few small rules for Origin, UPlay, Battle.net and Steam too plus the Firefox browser as those are unlikely to ever require full speed - though they are still 3D accelerated - plus as needed maybe also add rules for whatever other program might trigger the ClockBlock 3D detection, had to do the same with Rivatuner in Afterburner when I started using it too because programs like WinMerge - for text comparisons - apparently used 3D acceleration so nothing new there.)

Haven't ever had that Fury screen corruption bug while actually gaming but it happens on occasion, mostly when browsing certain webpages so I might try to keep Firefox as a block profile for a while and see if the constant clock speeds / higher voltage helps until AMD fixes the damn thing properly, going by the latest updates on the their forums it's under testing but no additional info was provided.

And now with Crimson 15.12 and 16.1 black screen driver crashes have occurred in a few games (Well, thankfully only two so far.) which is worrying but so far using windowed or when possible borderless display mode has worked for the affected games though I really wish I knew what triggers this crash, temps are in the 60's at most since I use a custom fan speed curve - oh why did they remove the min speed setting for Fury GPU's in CCC/CNext? - so I'm pretty positive it is a driver thing and possibly related to these clock speed switches and "power saving" stuff introduced in Crimson but that's but a guess for now.
(Don't really want to cause a crash but I'm a bit curious if forcing constant clock speeds now that I'm using ClockBlocker could maybe help with that too if that's what it comes down to, might try it one of these days.)

 

@ JonasBeckman: Yep, fallout 4 is a very big one with the clock issues apparently, especially indoors in buildings where they should be getting 120-144 fps.

On 3D-Detection, it's kindof a tradeoff as I see it. It's like making a choice of whether or not you want to add rules as exclusions or as inclusions. To me the problem with the idea of exclusions (and why I went with fullscreen detection as the default) is that you always have to be watching and monitoring to see if something is falsely detected.. But the log and tray-icon should hopefully help here with normal apps, as long as you have Windows set to not hide them.



We'll see on the blackscreen crashes. It seems to be another one of those things that's very variable for people, where some people don't have issues with the new drivers whatsoever (just like with the corruption, and also of those people that have system lockups coupled w/ the screen corruptions).

--I'm really hoping that AMD is able to track these things down. If you do find that they're power management related, in the games that you have blackscreen lockups in -- definitely make sure that you let AMD know. Every observation helps their developers, especially if they can't reproduce these problems on their machines.

And yeah, I don't expect people to go back and intentionally try to lockup their PC's, haha. That's perfectly understandable so this is just an if you run in to it again kindof thing. --Yet as a reminder to everyone, share your findings with software and behavior of blocked clockspeeds with AMD to give them a hand in tracking these issues down.

 

Ah the default rules seem fine to me and I find it very easy to set up custom ones as needed so no complaints from me there and yeah the tray color changes makes it very easy to see what programs might need to have rules set up, speaking of that I noticed a couple of the Win10 apps toggles the 3D detection too so I might give the wildcard suggestion mentioned earlier in this thread a try (*) and see if adding the entire Windows folder might be doable as LogonUI.exe (Ctrl+Alt+Del) and the various apps (Settings being what I use most for stuff like Windows updates.) likely have no use of full 3D speeds either heh.

On AMD's drivers and the Crimson re-design with all the work still being needed for that I'm assuming their driver team have their hands full so WHQL releases might be a ways off in favor for more beta releases and if needed also hotfix drivers.

I am glad they are prioritizing this screen corruption bug even if it might take them a while to fully replicate and then fix in-house before it can be added as a driver fix but I'm pretty confident it won't be too long now until it's resolved unless it turns out to be a deeper bios issue or something like that, would be unfortunate but it's probably unlikely to be that bad.

Hopefully fixing these occasional black screen crashes will also not take too long and although the chance of something actually being damaged either in software or hardware is fairly low I'm still not too comfortable trying to intentionally trigger this by testing under what condition it occurs but though I lose the ability to downsample running the games in windowed or borderless mode seems a good enough fix for me for now and hopefully it is related to the clock state switching and power-saving feature so this tool will further reduce the chance of it happening again.
(And yeah if I could reliably reproduce it under a specific set of circumstances contacting AMD about it would probably help getting it fixed faster, probably goes for a lot of other issues people are experiencing as well as their driver team can't possibly test against every possible combination of software and hardware so bug reports would likely be appreciated to narrow down these issues further.)

Anyways I'm glad I finally gave this utility a try, it's very easy to use and setting up custom rules as needed is extremely straightforward so no complaints there plus even if AMD's drivers determine that clock speeds can be reduced without sacrificing performance having them locked to full speed will have other benefits as well such as improving stuttering/hitching and the like, especially in games like for example Fallout 4 where it seems the speed is fluctuating almost constantly for whatever reason.
(A setting in the CCC/CNext options to force 3D clock speeds in compatible profiles or maybe even constantly - IE for games that don't yet have a profile in the current drivers. - would be a useful addition but there's probably a lot of work on Crimson/CNext as it is so any new additions might be a ways off as existing ones need further improvements and fixes.)


EDIT: C:\Windows\*, C:\ProgramData\* and C:\Program Files\* worked perfectly when added as rules.
(Windows for a variety of OS related software and system apps, ProgramData for Store apps - not that I use them. - and finally the 64-bit program files folder for various pieces of software, once I've moved the Steam library excluding C:\Program Files (x86)\* should take care of everything but the games I use, possibly also C:\Users\* for stuff like GeDoSaTo.)

(Alternatively moving all games to a singular folder and having downclock as standard and block for just this folder should also work, pretty flexible actually which is quite handy.)

(Or using priorities to simply have the Steam library folders block rule higher than the Program Files (x86) downclock rule.)


EDIT: Yep that will be it, I've set Windows, ProgramData, Program Files 64 and 32 bit and the Users folder to allow downclocking but have priorities higher for the games folder and the Steam library folder location and in testing this is working great so far.
(Could be fine tuned a bit further by excluding this or that launcher such as for Star Citizen, Elite, ESO and the like too if needed.)

 

http://gpuopen.com/

Its up, for developers by developers

 

I posted a link to this thread over at the Eagle Dynamics forums

http://forums.eagle.ru/showthread.php?p=2651796#post2651796

seems this program even helps out on some nvidia hardware

 

I am a bit confused with the different settings, ADL etc.
It says some might work and other might not.

Does that mean they will either always work or not,
or that it's completely random?

Cause ADL seems to work for me, isn't that then the best as it doesn't use any resources?

 

its pretty self explanatory dude.

method one uses a compute payload that is known to be quite reliable but has a bit of a toll on performance for things that usually max out your gpu. ( i loose fps in csgo for example, but that don't max out my gpu - but it works all the time )

method 2 uses a slightly less computationally complex load. ( it works but i haven't used it much )

method 3 or ADL just tells the drivers to go into full 3d mode kinda like how radeonpro does this in per-game profiles

method 4 uses a combo of adl and compute

 

yeah it works even on intel graphics, it should work on any gpu that can do openCL

 

Yes, that's what i meant.

The first to are "reliable and a bit unreliable".
So then i wonder, ADL works without any load, it just work with the drivers,
isn't that win-win?

 

You're correct on that ADL is pretty win when it works for you. (yields the best performance) However, which is better depends on how you look at it honestly. The ADL-method changes the clock-states available whereas the compute-method changes "absolutely nothing".


To list the benefits of ClockBlocker's compute-method:
-Arguably safer from the perspective that the driver clock-control is still 100% intact.
-Completely hardware generic. (works on many platforms to some degree, not just AMD cards)
-Can work in some video decoding cases that ADL clockspeed setting does not.

EDIT: For clarity, I have not run in to any games that ADL does not work in though. (only business type applications so far)

 

--This initiative is something that I'm going to be keeping an eye on.

If anything pops up in those projects that support new mechanisms of clock-control, I'll probably be adding them in here.

@ JonasBeckman: Nice!

That's a really sweet idea on how to leverage wildcard rules in bulk exclusions for things like Metro apps or the image viewer app.

@ Mustang104: Yeah, I wasn't sure that this would have any use for NVidia hardware (due to their already having some type of clock-control in their driver CP) ... but there was an early question on it in the Guru3D download discussion.

-Maybe some day I'll have to add NVAPI to the project to mimic NVidia Inspector's style of doing this.

 

I just thought i give some more feedback about the different blocking methods.
So far Compute is the best. I can keep my OC of the GPU at 1100 using Compute method.
Using ADL limits me to 1000mhz.

 

I just turned on my computer and clocks are stucked at max speed

ADL- method

changing methods doesnt change anything.

It was working as intended until earlier.

EDIT: tried to reinstall cockblock (delete configs) and msi afterburner, didnt work.

solution was turn overdrive on in crimson but you did recommend to leave it off.

 

Never seen this type of retention yet.

Do you happen to remember if the machine was shut down in some odd state, or not shut-down at all? (aka, a hardlock)


EDIT: To be clear on recommending that AMD Overdrive is not enabled. The reason that I'm making this suggestion generally is because it's very bad to have unofficial and official overclocking methods going at the same time. (TriXX or Afterburner in unofficial mode)

-Having just overdrive active standalone is probably OK, as long as other overclocking tools aren't mixed. It's the mixture of overclocking methods that leads to problems mostly [once enabled overdrive has its own clock retention].


You can think of this like having multiple programs attempting to set overclocks and fighting with eachother. (or in the worst cases their effects stacking)

 

Haven't had the clock speeds stuck like that although I noticed that if a game crashes Clockblocker has a tendency to be stuck in blocking mode (Helper module/process isn't unloaded properly? Just a guess.) until it's shut down and restarted, not really a huge issue so far.

 

I can confirm this when RB6 crashed. My clocks wouldn't go up to 1100 again but got stuck at 1000. Weird.