ClockBlocker (profiled AMD power-management control)

rofl, mind in the gutter man.

I like free. Holding you to this!

 

^ Says the person who brought up "FAP".

Roger that.

--Though I'll remind you that this is a long-way-away before there will be any form of a beta, public, private, or otherwise.

 

Hey there

Thanks for making such a cool piece of software

I use my GPUs for computing and for some reason, some older cards don't use their full clock-speed, so this is a great way for me to trick them into computing just right!

I did have one issue tho. On one of my rigs with multiple GPUs, it only works on the first GPU and not on the other ones. I don't have them running in Crossfire, since this is not good for computational reasons, and this might be the reasons the app doesn't notice the 2nd GPU.

Do you think there is a way/workaround to get this somehow fixed or integrated in the future?

Thanks a lot for making this stuff, it's much appreciated!

All the best,
V

 

Hey there Vazz,

Seems that I missed the automated board message. Was fairly busy in the process of picking up DDoS mitigation (for ComroeStudios) and moving several servers, one of which happens to run my email. This was over the last two weeks roughly, so that's probably what happened..

--IF anyone had issues getting to the site or from ClockBlocker on its update check -- this is the reason. Yet that's now out of the way and I'm finally back to working on "YAP".


Anyway, getting onto that question.

The compute method actually doesn't know anything about the status of Crossfire, although the cards being in CFX might have an effect on how their driver clock-control works. Possible that you can get me a log of enabling blocking on the machine? (the one that isn't in CFX)

Also anything more on the hardware of that machine, specifically if it has an IGP (eg, knowing the CPU model) in addition to the second card. When blocking is turned on with the compute method, the log should should state the number of candidate devices and also show you the status of initializing CL or DCU on each individually. (or rather, if there's any errors)


--So, in this case since you have a machine with two cards: you'd expect to see 2-3 candidates. Anything less and the second card isn't being detected for whatever reason.

Ironically it's the other way around usually (of problem reports I've gotten), that a second card doesn't show up when in crossfire whereas it works when not combined.

 

Hey Razor,

Thanks for getting back to me! no worries at all, it's a busy time

I am running on a 1800x Ryzen here. I did as you said and if I use the compute method, indeed 3 device candidates are recognized in the logs and they all seem to work. However, my problem is that these 2 cards (Radeon 7970s) don't use their full 1050Mhz in this computation but only 1000 (regardless of CB being activated or not). Only when I use the ADL method does one of my cards reach the 1050Mhz continuously. It is also only with this particular app, if I use other stuff with them, they reach their 1050mhz no problem. It also doesn't matter if I overclock anything else into the cards, the 1000Mhz just stay unless I use the ADL method.

I know this is probably too specific now, since I didn't know that the compute method does in theory work on my machine, so thanks for clearing this up. I will just have to live with the 2nd card being at 1ghz I reckon, it's not a huge deal, but it was annoying enough to find out why exactly and I hoped with the ADL on both cards I could circumvent this hehe

Hope you have a lot of success with your new project and thanks again!

All the best,
Vaz

 

Yeah, it's actually funny. I felt somewhat loved (flattered) that I got attention, even if it came in the form of an attack. (DDoS)

Ah, the 1000 vs 1050 issue. Yep, this started being a problem on the Fury's as well around 16.12.1.

Another option is to wipe out the intermediate power-states with a custom vbios. This is probably the ideal-way to handle it per squeezing the absolute maximum performance, yet of course that has the downside of messing up your power saving otherwise.

Thanks! --It's coming, slow but steady.



Dark themes, etc, will be possible this time. Overall I'm looking to combat one of the big complaints people had with ClockBlocker (that it looked "bland" / people disliked the UI's look).

Of course, also the only "Windows" specific code in here right now is the process interrogation. Trying to stay platform neutral / portable.

 

YAP? Whats that? Am i missing something?

 

In jist, ClockBlocker Profile System + Task Manager + Networked Communication + Linux = YAP.

In otherwords you don't just set GPU priority, you also can set process priority for games, kill games from another computer (on your main desktop), etc.

-YAP is also service based, rewritten from scratch, and is going to simply be better than ClockBlocker in reading process information. For instance, it can in "all" cases read the full path of applications.

 

All-in-one program, alright i like that!

A cool think will be auto updates-check for updates...instead of downloading each time a new release is out

Peace!

 

Sure, I'll add a "real" auto-updater to the list of things to code. We'll make it not just download, but install the files and run a hash-check, not just through a one-click (/silent mode) installer as ClockBlocker did it via.

The combination of programs I see as a natural evolution in this case, since squeezing performance out of games isn't just pushing the videocard ... yet also beyond that making sure a game gets all the CPU time it needs to feed said video-card. ClockBlocker as its initial purpose of blocking downclocking probably won't be needed forever either, as AMD continues trying to tweak their built in driver-control. So, I am branching out to find other useful things that we can have the tool do.

The networking angle just makes a ton of sense (especially as gamers), because alot of us have many PC's. In this way we can basically set game priority settings mid-game, add a profile, turn on clock Blocking, kill a crashed game process that won't let us open TaskManager, or investigate performance.

^ without alt-tabbing from fullscreen-mode

I have alot of plans for YAP. May be adding things in here like networked screenshot, with screenshot viewing on the remote system.

 

Just a quick question about CB, any idea why it's crashing on my 1950X System???

https://imgur.com/a/eHpWN

 

Nope, and that's interesting if it's specific to threadripper (considering I don't do anything processor specific within ClockBlocker). However, I see that the crash is in the controller program and that you've got a nice BugTrap prompt showing there.

--If you can save that dump like so and send that to me, then I can get alot more detail of exactly what's happening at the time of the crash.



Just email the crash-dump to , and put something like "ClockBlocker dump" in the title with a brief description "if" you did anything other than just starting the software that triggers it. I'm assuming this is just an instant-crash on start, though.

 

It's immediate crash on startup. Software install's ok though. Happens with both 32bit and 64bit. Just a really odd thing to pop up. Email sent with the dump though.

 

Got the email and the crash-dump. It seems the ultimate cause of the crash is inside of ClockBlocker's custom ListCtrl during drawing the "Rules" settings tab. However, the state that the program is when it's reaching here that's resulting in the crash is interesting to say the least, since it probably implies corruption of some sort. (wouldn't normally happen)

While I could change the ListCtrl to stop the crash, I'm more interested in how it's getting in to such a state.


--Please check my email response, I'll probably want a copy of your config files.


EDIT:
Also forwarded email as a Guru3D conversation incase there's mail problems reaching hotmail.

 

Config files sent

 

Thanks!

Yep, there is indeed an issue in those config files. More followup on observations so far sent by email.

EDIT:
--There is enough redundancy in the config files I believe to salvage them.

I will be putting out a hotfix soon to also take care of the crash.



Update:
Download the latest version, rename your damaged config files folder back, and you should be good to go.

As I had your config files for testing, they're used as the basis for the changes and they should just work again.

 

Downloads linked here.

I've also made the decision that 1.3.3 BETA was out long enough, and to make this release available via auto-update, installer, and standalone.
--If I didn't, YAP might be available before I did, heh.

While YAP (next generation of ClockBlocker) is taking most of my spare-time, I'd like to remind everyone that I will still of course do maintenance on ClockBlocker. Or rather, try to fix any major reported crashes.

 

Thanks very much for that A2Razor

Confirmed all rules are back in place!

 

Don't know if it is the latest update of Clockblocker or the W10 FCU, but I have Clockblocker run at startup and UAC is asking to allow it to run every time.

 

I'll have to look in to this.

ClockBlocker does need administrative rights and mandates it via manifest, however the scheduler entry should've bypassed the UAC prompt. Most likely the result of the fall update.

EDIT: To be clear, no change with ClockBlocker's startup from 1.3.x vs the older 1.2.x (both are via scheduler + manifest). A quick google shows that ASUS' suite is having similar startup problems on FCU. Yep, looking like Microsoft must've done some security enhancements here.

YAP inherently won't have problems like this, since YAP will be using the service model for elevation. The client (tray program / Control Panel) won't need elevation, though I understand this does nothing for helping right now. I'll see if I can find out more and get a system setup on the Fall update for testing soon.