Unsupported Ryzen Instructions
Ryzen processors shook up a stagnant processor market with more cores at competitive prices. Recent models have closed the gap on single-core performance, leaving few major weaknesses when compared against Intel processors. However, Ryzen has historically had growing pains supporting the full instruction sets provided by Intel, some of which still exist to this day. The situation has largely improved over time via microcode updates, BIOS patches, and new processor revisions.
Processors use feature flags to convey which instruction sets are supported. If the associated flag is set, software can safely call those instructions, often with performance gains from calling a single specialized instruction instead of a large sequence of more common instructions or providing extra features.
On Ryzen, these enable bits are often set even when only a portion of the instructions are supported. This is the case for 16-bit legacy instructions. These instructions are used when virtualizing '90s-era operating systems, such as Windows 98. Ryzen processors falsely claim full support for these 16-bit instructions, even though actual support is only partial. This is frustrating, as not claiming support would allow VMware to seamlessly fall back to virtualizing the required instructions in software. As it stands, the config needs to manually be adjusted to request software mode for these instructions, even today.
Instruction support has plagued the launch of popular video game titles. In the early days, Destiny 2 failed to run on Ryzen systems without a BIOS update. While details are scant, the update presumably added support for instructions that were used by the game that were improperly handled by the CPU. Red Dead Redemption II was similarly affected.
A particularly egregious example was the way Ryzen handled random number generation. Some processors have instructions designed to provide fast random number generation in hardware. Ryzen claims this support, yet its initial implementation always returned 0xffffffff, or -1 in signed 32-bit integer representation. To resolve this, Linux kernel developers had to ignore this instruction even for processors that claimed to support it.