Destiny 2 AMD Ryzen 3000 Issues solved with chipset driver update
Click here to post a comment for Destiny 2 AMD Ryzen 3000 Issues solved with chipset driver update on our message forum
Astyanax
It actually is known why Destiny 2 wouldn't launch,
the game makes use of the RDRAND x86 instruction on Intel Haswell+, and AMD Jaguar+ architectures, AMD's implementation is guilty of returning -1 after coming out of certain power states, instead of a value in an expected range as the Seed would determine.
This should only have posed a problem on Zen 1/2 after a Sleep and resume cycle, but because Ryzen 3k is completely sleeping individual cores it was experiencing the same thing without such a cycle.
Reason for this is that AMD doesn't implement core entropy states.
What is not known is how the chipset driver resolves it.
Is it saving the state prior to letting the cores sleep and then restoring them on the next time the instruction is utilised?
Is it virtualizing an entropy state or just emulating the instruction entirely?
signex
LOL that's why it would not launch, i had no idea it was my 3600 causing it. 😛
EDIT: Installing that chipset driver now to test.
Astyanax
It apparently doesn't work if SVM is enabled in the bios, suggesting there might be some register save and restore trickery at work.
Astyanax
it was supposed to be a bios update, but they are resolving it with a driver right now.
Astyanax
Robert said this game isn't in their testing suite because its highly difficult to get any performance numbers from it.
Also they probably weren't expecting their lack of core entropy to bite them in the ass this way (far as i know Zen2's low power state is much like how the cpu goes to sleep in S3 standby)
asturur
Testing all popular games is nearly impossible.
I bet there are test suites for every single x86 instruction and combination of them and parallel executions of them.
All in all testing games on a cpu is not what I would expect.
Is weird to me that none of their test caught that the instruction wasn't working in a particular power state, or that the core is not waken up on that instruction, but this is not something you find out running a bunch or a ton of games.
Astyanax
I'm surprised it wasn't caught on Raven Ridge first, since it also implemented CC6 and CPUOFF.
schmidtbag
The fault is on their end, though, it's unrealistic for them to test every popular game. And even then, Destiny 2 isn't that popular.
The more confusing issue is how they somehow didn't notice booting issues with Linux. I understand the Ryzen series isn't really all that interested in the Linux desktop, but, if Zen2 were released on Epyc first, that would have been a much bigger issue. On the other hand, they also probably would've noticed the problem long before launch day if they released Epyc first.
AlmondMan
It's Destiny 2 on Linux... like .01% of people affected.
schmidtbag
Actually, Destiny 2 doesn't run on Linux at all; the problems are separate, but, they're both related to the same underlying issue (rdrand).
signex
The driver does fix it, played it this morning for an hour.
anticupidon
RDRAND x86 instruction returning -1 is the culprit of boot issues on Linux distro with systemd requesting the value from motherboard firmware
SpajdrEX
Not having it too on my B450 mobo anymore.
NCC1701D
There is supposed to be a major update tomorrow from AMD. I don't know if it's an announcement or an official bios roll out, but they are supposed to have some details. This announcement is going to supposedly address the high voltage at idle, WHEA errors, and Destiny issues. There is a long thread on Reddit and an AMD representative is supposed to be posting there tomorrow with the details. I would imagine an official bios will be out soon to get your power profiles back too.
TieSKey
The game completely crashes for a single out of range random number? and the devs pretend users to wait for and install a complete bios update instead of actually patching their game????
I'm not defending AMD, just saying the game devs are treating their customers (ok, a small part of them) like shit..... patching that should be a 10 min task ....
Astyanax
VESA modes have nothing to do with x86, so im not seeing your point here.
have you seen the game code and how much relies on that instruction?
schmidtbag
To be fair, it is just simply a random number. Most other games that use random numbers (which is presumably most games in general) don't seem to have this problem, because they're fine with using the software-based seed.
But... I still don't think Bungie is really obligated to make a patch because of AMD's mistake, especially since AMD already said they were working on it. It'd have been nice for Bungie to just release a patch anyway, but I don't fault them for not bothering.
Astyanax
I'm extremely curious how the chipset driver managed it, i'd hope it was temporary and a bios change was still coming because of it requiring SVM disabled.
schmidtbag
The chipset driver is probably a catch-all term for "everything revolving around the Zen platform". I wouldn't be surprised if the driver update was just a temporary fix that maps rdrand calls to urandom or whatever. Not the most ideal or secure method, but, better than having nothing at all (or errors). If that's true, hopefully they'll get a more permanent fix.
TieSKey
While ofc I don't have their code I'm a systems engineer (with a masters degree and phd student if that actually matters 😛) working on RA/AI and a hobbyist game dev so I'd bet 1 month of wages it's a 10 min fix. (Unless it's on some sort of drm shit :S)
