We were not able to reproduce this issue. We tested on a clean build of Windows 10/7, fully updated no other software installed other than the latest driver and the clock speeds behave as they should.
We will take another look at the issue if we get more reports.
If anyone experiences this issue, please provide a summary of your issue and your can provide your full system specs, as well reproduction steps.
A lot of people two years are reported about this mistake, and you hide, even at your forum is full of messages, the last working driver without uvd of a mistake 16.7.2
All, i've been stumped by this UVD clock state issue for a long time, and as a result i've continued to stay on 16.7.2 to allow idle clocks and boost clocks. However, today, i discovered how to restore access to all clock states on 18.5.1. I had a program in my task bar called NokiaSuite - yes i'm still kicking a Nokia phone. When running this app, my GPU would only use UVD low and UVD high clock states. Upon closing it my clocks went immediately to idle 300/150. Opening up a 3D application now brings up Boost clocks. I recommend to anyone still experiencing this issue to try looking for applications and killing background software that might be tasking the GPU by stealth like NokiaSuite. What's unclear is what has changed from 16.7.2 to later driver versions that leads to this different clock state behavior in relation to NokiaSuite. FYI, my GPU is an R9 270.
Software i've identified so far that seems to cause undesirable clock state behavior includes:
NokiaSuite v3.8.54 - when loaded in taskbar, the GPU will only utilise UVD clock states.
AMD UVD Decoder (13.3) - video playback with this decoder leaves clocks locked at UVD low (450MHz) after quiting video player. Alternative decoders such as Microsoft DTV-DVD Video Decoder and LAV Video Decocer test good, allowing 300/150 after video playback is discontinued.
Please, MSI AB has nothing to do with it, the only thing in common are all drivers after 16.7.2 which was the last one unaffected. I could trigger this bug immediately without third party OC apps on 3 systems. All on W10 x64 (with all drivers after 16.7.2), A friend's 280X + P55, and on my previous 7970 + 790FX, 7970 or 7870 + 890GX (with two very different 7870s, regarding bios version and pcb). Currently I only have the 890GX+ MSI 7870 at hand:
W10 x64 any version + any driver since 16.7.2
MSI R7870-2GD5T OC (reference pcb with custom cooling) with latest vbios TV274MH.161 (did it also on stock bios)| in the past also ASUS HD7870-DC2-2GD5-V2 (custom pcb/cooling) and HD7970-DC2T-3GD5 (custom pcb/cooling), both with stock vbios did it on this system (I don't have access to them).
ASUS M4A89GTD PRO with latest bios 3029
PhII 955BE X4
PCP&C 750W (Seasonic)
HP w2207 via DVI (on other system with a u2311h and 7970 it happened both with DVI or DP, all single monitor, and unrelated to higher idle clocks on multi-monitor setups)
I've reported this issue with instructions on how to reproduce it with a CGN 1.0 card a lot of times in the submit form:
Step 1: Launch a clocks monitoring tool like hwmonitor, and ensure you're at correct idle clocks 300/150
Step 2: Launch Chrome with HW acceleration enabled, go to Facebook (or any similar heavy page that will store many MBs of stuff on vram) and scroll down a lot, until clocks jump to the lowest UVD clock and stay there after you stop scrolling (this is very important). Wait a bit, and confirm it doesn't revert to 300/150 -- if it does so, scroll down a bit more until clocks go up to UVD states and rest and the lowest one after you stop scrolling. This would be 450/1200 on a 7870, further clock examples will be on it.
Step 3: At this point, launch MPC-HC and play a video with a decent resolution that will use DXVA acceleration. When you do this, clocks must still be at the lowest UVD state (450/1200). Then, they'll jump to 1000/1200 (1050/1200 on this pre-OC'd model) while playing video which is the highest UVD state, that will be the same as the highest 3D clock. This is expected on a non-boost card, but a boost card like the 280x will have the highest UVD state clocked significantly lower than the boosted 3D clock it uses on games.
Step 4: Close MPC-HC, then close Chrome and you'll see the UVD bug in action, because the card will be forever stuck in UVD states. Clocks will stay at 450/1200 on desktop without anything running. So if a game is started, the card will switch to the highest UVD state, instead of the highest 3D clock state. To resume proper operation, it's required to reboot the system or reinitialize the driver (restart64.exe from CRU, and probably win+control+shift+B).
On non-boost cards, those clocks will be the same and it'll only cause higher power consumption at idle. But if a manual overclock was applied or is applied with the bug triggered, it'll be ignored because it's tied to the 3D clock, not the highest UVD clock (which incidentally is the same on these older cards, making the bug harder to notice stock). It makes no difference if it's done via driver or MSI AB, these aren't the apps at fault. With boost cards like the 280x, the problem is more obvious because the highest UVD clock it's stuck on is lower than the 3D clock, and gaming performance will suffer even without any OC applied.
Also, the above is particular only to CGN 1.0 series (7850/7870/7970/265/270/270X/280/280X/370, Pitcairn and Tahiti based). The reddit thread that was linked with mostly Hawaii and later users reporting issues pertains to other problem that caused some cards vram to be locked at idle clocks, it doesn't affect CGN 1.0.
Thanks for looking into this.
We have been unable to reproduce this issue so far, the clocks reset to the default values as expected.
Below are the steps we took and the specs of the systems we tested:
Ryzen 7 1700X
HD 7870/R7 370
Win 10 RS4 +
We're going to need alternative instructions on how to reproduce this issue.
Start several Media Player Classic windows at the same time, also you will reproduce uvd bug. How so left that we people the bought AMD cards have to beg you to correct your errors?
That's not how you do it.
Open Chrome. Open Facebook. Scroll down and trigger the HW Acceleration clocks, in my case 501/1500. Once they're there and not going down, you open a video in MPC. See how the clocks go to 850/1500. Close everything. The clocks are now stuck...
If this sounds like a far fetched scenario, it happens to me every damn day. I'll open Chrome, send messages on Facebook, check my feed, trigger the HW Acceleration clocks, forget about it and then open a video somewhere, say a movie. Get stuck on UVD clocks and only remember it later. This is not a nice thing to happen and it happens to me every day. The drivers don't function right. It was all good until 16.7.2....
You are most probably failing to do the detail what I've underlined twice in the instructions, because your reproduction steps don't mention it properly. When you scroll enough in Facebook, clocks must jump to 450/1200 on a 7870 or 501/1500 (as per maverique's 280x example) and remain there without going back to idle 150/300 even if you change a tab and let it rest for a while. This is very important. Only then you can launch MPC-HC to play a DXVA2 accelerated file to trigger the bug.
Btw, given that most clips on YT are VP9 accelerated under Chrome instead of DXVA2, they shouldn't affect the UVD.
We were able to reproduce the issue after opening Windows Game Bar. Once it is fixed it will be called out in the release notes of a future driver release.
Thanks for your feedback!
I've never noticed in that condition because I run windows with both Gamebar and Fullscreen Optimizations forced (via registry) off, as the new hybrid fullscreen mode can be problematic.
Beware that there are two different scenarios were UVD related problems can happen on CGN 1.0:
1) The one I mentioned above leaves you completely stuck at UVD clocks even without anything running (450/1200 on desktop and the highest UVD clock for 3D*) , and only re-initializing the driver via reboot or CRU's restart64.exe will make it return to regular clocks. This is the one that will happen on any driver after 16.7.2.
2) The other one, I assume it's expected behavior unlike the previous, but can also be problematic and hinder performance. There are cases where games or software use intros/elements that trigger the UVD states, and then when a 3D scene is started, if the previous UVD accelerated instance hasn't been properly finished in time, the card will then run at the highest uvd clock for 3D instead of using the correct 3D state. This is problematic on boost cards with lower high uvd clock than 3D clock. Usually these cards will only change to the proper 3D clock when a 3D scene starts and the card is resting at 300/150 instead of UVD clocks.
One very easy way to check it, is running a light clip in MPC-HC that makes the card go to 450/1200 while playing (just make it a small window), and then at the same time, run the 3D render test on GPU-Z (the "?" next to the pci-e bus speed). The card will jump to the highest UVD clock instead of the correct 3D clock state*.
But unlike in the first problem, after all software instances are closed, the card will go back to proper 300/150 clocks on idle. This problem will happen on any driver, including 16.7.2 and before, which are free from the first.
* On a older non-boost card were 3D and highest UVD clock are the similar, applying a 3D overclock is a easy way to distinguish between, because it isn't applied to the UVD state.
How about problem with GCN 1.0 UVD clock&sleep? If you watch video in browser and send PC to sleep, after wake up videocard stuck on UVD clock, until you reboot PC. The last driver without mistake 16.7.2. Sorry my english is bad.
I'll paste back what I've wrote on guru3D about the fixed notes on the driver:
Graphics and memory clock speeds may remain elevated or locked while gaming if video content is also playing on the system."
Well, I can't reproduce the CGN 1.0 bug anymore in the same way I've always consistently triggered it. This driver seems to have finally fixed it.
The behavior is back to pre 16.7.2, but this also means that the driver fixes statement above doesn't apply for these cards. On a CGN 1.0 HD7870 (pre OC'd Sapphire at 1050/1200 3D on stock vbios), while playing a video that causes clocks to switch to 450/1200 or 1050/1200 (both UVD modes), or by letting chrome cause the card to idle at 450/1200, then initiating 3D content such as the GPU-Z render test will cause the card to go to 1050/1200, but that is the highest UVD clock, not the 3D clock state (same stock values on this card).
This means that any OC applied via software over the 3D clock won't be used because the card is running in the upper UVD state instead. The same will happen by launching a video on mpc-hc, leaving it playing and launching a game in (true) FS mode -- OC won't be applied because the card is in the highest UVD mode, not 3D. Can't comment on a boost card, since I haven't any to test.
Just to add, since I can't edit. The driver solves issue "1)" (uvd clocks stuck until reboot) but not "2)" (card won't raise to highest 3D power state when starting a 3D app while low/high UVD is active and other content is still using it) that I listed in detail a few posts back in this thread. But 2) affected these cards since the beginning, and the only way to workaround it, was to use the unnoficial OC mode with powerplay support that was available in MSI AB, but drivers don't have that OC path available anymore since about a year ago. Thanks.
No.2. If iirc, not reaching full clock on the boost was expected behaviour if another app(e.g. video clip) was using graphics. Sapphire(at the time) had a small article explaining the bios boost function(can no longer find it).
The same bios boost applied to some rebadged 2xx models, I remember thinking 'why buy if boost is limited under certain conditions'.
The UVD Clock fix for GCN 1.0 Cards is fixed in 18.8.1 and 18.8.2.
UVD Clock bug is present again in 18.9.1, 18.9.2, 18.9.3, 18.10.1
It looks like GCN 1.0 users will have a new driver to be stuck on for a few years until AMD decides to grace us with a merge of the bug fix into current drivers again...
Good afternoon Matt. I'm using an Asus 280x / Asus P7P55+ combo and this definitely happens. When something triggers the 501/1500 clocks, like, say, Chrome, and I open a video on Media Player Classic or some other program, the clocks get stuck at 850/1500 and never come back down after that. I'm using Windows 10 1803 but this bug has plagued me and many others since 2016.
Thank you for your attention
To clarify, instead of 300/150, my clocks get stuck at 501/1500 and don't come back down from that. They will go to 850/1500 when playing videos, for example, but after I close everything those clocks are stuck at 501/1500 and never ever come down again. Even with all my programs being turned off. The last good drivers were the 16.7.2 version, which don't trigger this bug at all. Every single driver since has had this problem.
There is also the UVD frequencies bug for GCN 1.0. If you view video while the frequency of the card is on max, it will never clock down to normal 2D clocks, but remain stuck forever at 500/1500.
I have reported this at least 9 times now, they won't even acknowledge it.