Patch dispatch from High Command For this patch we bring you a number of adjustments fixes and improvements do aid your democratic endevours Overview For this patch, we have made improvements and changes to the following areas: Balance changes to weapons, stratagems, and enemies Change to the Spread Democracy mission Balancing General Armors with armor rating above 100 now also reduce damage on headshots. Victory poses will now only play for the extracted.
In my case it manifested as a graphics driver crash. This would bring down anything that was using the GPU: the game, discord, Windows DWM.
Someone on SC`s forums did a bunch of research and eventually suggested the clock limit, which has solved all my SC, HD2, R&C issues and most of my War Thunder issues (though that one still silently deletes itself from RAM occasionally, but I think that’s just War Thunder).
I forget, it’s been a while. I want to say yes, but the screen would freeze for several seconds before the GPU driver reset in my case, so that seems like a legitimate timeout to me. I had tried increasing the timeout in the past to fix these issues, before I found this method.
While testing I did confirm using OpenHardwareMonitor that the GPU core frequency would spike above 3100Mhz before crashing, as the thread describes. Setting the max to 2550 seems to prevent this happening.
In my case it manifested as a graphics driver crash. This would bring down anything that was using the GPU: the game, discord, Windows DWM.
Someone on SC`s forums did a bunch of research and eventually suggested the clock limit, which has solved all my SC, HD2, R&C issues and most of my War Thunder issues (though that one still silently deletes itself from RAM occasionally, but I think that’s just War Thunder).
Here’s the post, if you’re interested: https://robertsspaceindustries.com/spectrum/community/SC/forum/50174/thread/high-end-amd-gpu-crashing-possibly-resolved-we-nee
Sorry, I take a bunch of acronyms for granted. TDR = timeout detection / recovery.
Did the bug report tool suggest there was a timeout in each of those cases?
I forget, it’s been a while. I want to say yes, but the screen would freeze for several seconds before the GPU driver reset in my case, so that seems like a legitimate timeout to me. I had tried increasing the timeout in the past to fix these issues, before I found this method.
While testing I did confirm using OpenHardwareMonitor that the GPU core frequency would spike above 3100Mhz before crashing, as the thread describes. Setting the max to 2550 seems to prevent this happening.
Thank you for the info!