Really glad to hear that.
This issue has now been resolved in 18.8.1.
When AMD will fix UVD bug? 280x GCN 1.0 the last driver without mistake 16.7.2.The mistake is one and a half years old
Why i cant report those troll/meme posts ??
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.
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.
I wrote you
1. Come into a game
2. Win + G Windows Game mod frequency will get stuck UVD bug
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.
I'll pass that feedback on, thanks.
Thank you! this is very annoying and we hope to help you fix it.
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.
Oh my God, really
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.
driver 18.8.1 fix UVD clock bug for my HD7850.
yes it is probably really corrected.Thanks
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.
My screenshot. This happend every time if send PC to sleep when it play video in browser or videoplayer.
ou hide a problem, you don't have belief, I have two years uvd bug problem, I any more will never buy the video card AMD
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.
I've posted above that i will ask engineering to look at it.
You officially don't recognize that the problem is, you can't just solve it and have decided to hide
There are news?
I've opened a ticket with engineering. If i have any further updates i'll post them here.
HI , i might found a quick fix you guys , at least it works for me , i made an account special to tell you this fix as i searched for 1 in a long time.
What i did its very simple , ive downloaded RadeonMod and on the Tweaks Tab i disabled ULPS then pressed restart drivers. (the last option there is UVD Clock FIX , and its on by default if its not just enable it!). Now i can be on youtube and twitch and play a game at the same time and the card uses the boost clock. I have an Asus r9 280x , before doing this if i had youtube/twitch or anything that used UVD and i was starting any game the clock was sitting at 970 now is sitting at 1070 as it should. Hope this will help you guys too. Best Regards.
RadeonMod (Tweak Utility) | guru3D Forums
Disabling UPLS isn't a solution for the problem I've listed above as "1)", which is the perma stuck UVD clocks. It might be helping you with "2)" (uvd to correct 3d clock transitions) under specific circumstances, but I've just tested with mpc-hc playing and then start gpu-z render test, and fails to apply the proper 3D clock.
In the past, the best way to solve "2)" was to use OC apps that applied clocks in "non-official mode with power play support" such as MSI AB and Trixx before it was removed from drivers. By that way, 3D clocks could be started from a UVD state, not requiring the card to be at 300/150.
Hello, i just have the same problem but i was not aware what it was before some research, for me the bug is on since computer is turned on.
I got an Asus strix r7 370, with factory OC to 1050mhz but I was kinda worried about my idle temps being so high (56ºc) so I changed the thermal paste and saw no change at all, I've realized that on idle was very hot and on load it won't even do the factory OC, and was only at 925mhz (the stock clocks) and it supposed to run at 1050mhz, then I downloaded the GPU tweak II from the asus page and saw that even won't overclock at all.
After some days on google, I've used DDU to reinstall the drivers (I've tried with the last 3 driver versions available to date) and tried disabling ULPS and nothing, I saw a video about editing the bios so the UVD state has the same clocks as the performance state but i don't want to do that, I thought this was fixed and yet many people on the internet noticed this and the RX series has the same problem too and i guess some people has the bug going but won't even noticed because they don't know about computers.
for me bug is on since startup (win10 up to date)
[Normal operation]ASUS STRIX R7 370 (is overclockable)
Load (1050mhz core / 1400mhz vram)Idle (300mhz core / 150mhz vram)
Temps (idle 35ºC / Load 69ºC)
On the GPU Tweak II there is an option called "Overclocking range enhancement" that do what it's name says but has to disconnect/reconnect the gpu, that allows to the gpu be back to the normal operation on which drops the temps significantly.
ASUS STRIX R7 370 (is NOT overclockable, you can move the settings but it won't change anything on the HW Monitor)
Load (925mhz core / 1400mhz vram)
Idle (450mhz core / 1400 mhz vram)
Temps (Idle 56ºC / load 66ºC)
I took a peek on the bios editor and downloaded the bios knowing what's going on and yes those are my UVD settings and not the performance clocks.
Temps and power are a matter that concerns me, since the normal operation only reach 35ºC and with this bug and from the start reach 56ºC at idle!, I had to set a custom fan curve just to keep it at 50ºc idle all the time.
So please I hope this could get fix soon, I bought this card because the RX series is so expensive on my country right now, and knowing the bug affects the RX too I have to check on my friends to see if they had the bug too and are unaware of it, so i write here to let known to AMD people that there is many more people with this bug than you may think.
If you wan't an immediate solution without frequent manual driver resetting or bios editing, your only option ATM is to use 16.7.2 drivers.
Thanks! so... this is a driver fault then? do you think if do a clean reinstall of windows could I get rid of the bug?, anyway I'll install the 16.7.2 thanks again.
Don't bother reinstalling windows, providing you haven't something running in the background that causes those clocks (so then it's a different problem related to "2)", as I explained on a previous post on a post), this issue ("1)") will happen on any driver after the 16.7.2 set. Just test them and see what happens.
I have an msi r9 280 in my bedroom pc
and can confirm that the uvd bug has been present since 2016
how amd say they cant reproduce it is beyond me
its simple to reproduce
they clearly arnt using the right card or are not monitoring clocks properly
The stuck clock bug may be fixed but
the clocks arnt
Play AVC video on Media Player Classic on monitor 2
Start Game on monitor 1
Results in the R9 280 running at UVD speeds even though a game is playing
e.g. 827mhz instead of 1000mhz
can we expect a fix for this quicker than 2 years?
The issue reported by the OP has been addressed.
If you have a different issue, open a new thread on it.
Uvd bug returned with the version of drivers of AMD 18.12.2 again. Help please
Uvd bug returned with the version of drivers of AMD 18.12.2 again. Help please!
Yes, this issue "2)" has been in CGN 1.0 cards since as far as I remember (late 2013', since didn't have one before).
They simply won't switch to 3D clocks if a 3D app is started at the same time something is already making the card use UVD clocks, 3D clocks will only be correctly applied if the card is resting at 300/150. This was tolerable with the first gen non-boost cards running stock, because the highest UVD clock is equal to the 3D clock as in my example above. The nuisance would be apparent when using a OC over the "true" 3D clock, as it would be ignored.
But it becomes a problem on boost cards where the highest UVD clock is considerably lower than the boosted 3D clock, like on your 280.
The driver fixes note seems to address this issue in the way it's phrased, but it only solves the stuck UVD until reboot problem (still, MUCH appreciated!).
Retrieving data ...