AMD Radeon Adrenalin Edition 18.1.1 Driver download
Click here to post a comment for AMD Radeon Adrenalin Edition 18.1.1 Driver download on our message forum
JonasBeckman
So it's waiting for AMD to fix the problem in a newer driver or rolling back or forcing clock states either in a third party software or through bios editing.
Not the most ideal situation or workaround for either of these choices, AMD should really fix the issue with certain GCN 1.1 GPU's getting stuck on a lower clock state but there's been reports for a few month now or over a year actually going by you having to roll way back to a 16.7 driver for it to be resolved and then going back to that driver and the issue is solved so it's something in the later GPU's, is that when AMD switched to Wattman and forced older GPU's to use OverdriveN? It probably is.
(7000 series should be GCN 1.1 or GCN Generation 2 I believe, 280 being more of a rename and slight tweak of that same architecture which as far as I remember with the 280 matching a 7800 type GPU and 280X matching the 7900 GPU.)
Looks like the focus is squarely on the 500 series and Vega currently then so who knows how long it might take them to work out this particular bug then and editing the power states means the GPU would remain on I think it's the p6 and p7 mode constantly thus heat and more power drawn which is a bit of a brute force approach and not really recommended unless there's really no other alternative though I guess that's what it comes down to until it gets patched properly.
Also, I thought the issue had been around for perhaps a few months now not one and a half year and counting. That's really no good at all and kinda dampens AMD patching the issue ever with how long it's taking.
(Long as it took for the problems with the 290 black screen crash and Fiji and it's display corruption this is something else entirely.)
AlleyViper
HD7800/900 are CGN 1.0, so as R7 265, R9 270/x, R9 280/x, R7 370 (can't be bothered to remember lower models). CGN 1.1 (sometimes called 2.0) is R9 290/x and R9 390/x, and then 1.2 (by the previous numbering) is R9 285, R9 380/x. R7 265 is a rebadged 7850 with boost, while the 270/x are rebadged 7870s with boost and higher memory clocks (being the regular 270 more TDP limited), all are Pitcairn CGN 1.0. R9 280 is a rebadged 7950 with boost, while the 280x is a rebadged late model 7970 GHz (boost) with less base clock and way less tdp available for the reference card, all of these are Tahiti CGN 1.0.
AFAIK CGN 1.0 isn't affected by a permanent stuck lower state, that pertains to another more recent bug different from the "CGN 1.0 UVD bug" I was referring to which came after 16.7.2 (which limits the card to vary between UVD clocks only), even if it also has to do with power states. Someone more knowledgeable about it could tell you, but IIRC the newer stuck lower clock bug usually affects later CGN 1.1 models like the 290/390 series, don't know if CGN 1.2 285/380 are affected too.
JonasBeckman
Got it, also sounds like a bit of a mess then if there's this issue you've mentioned with the above post and then a separate issue with UVD and clock speeds too in addition to a few other well known and often mentioned issues that have persisted. 🙂
For this issue since the product is still actively supported it should still be looked into and fixed though at least the above quote confirms AMD is aware of this or at least one of these clock speed problems but it's complicated to fix.
Still better than silence at least but if there's two separate issues that's a problem since what happens if they fix one and the other issue remains.
I think there was also a issue with Polaris where it could end up in a lower clock speed mode but I believe it had something to do with bios adjustments and the memory settings so it could be something entirely unrelated.
Well, 18.2.1 hit and the known issue seem to be primarily Freesync and Relive issues so my guess would be that AMD might be trying to focus on these first but it's just speculation, that 12 GPU configuration issue has also been around for a few drivers now but it's not a very standard setup and then there's the compute -> workload switch causing a issue with Crossfire systems which has also been listed for a few drivers now.
Nothing to do but wait I suppose and see what comes next, glad to see some communication from AMD however but yeah it sounds like a problematic situation form what I'm reading and hearing then and if there's multiple issues that's going to be a problem.
David3k
OnnA