CDPR can't seem to catch a break with the launch of Cyberpunk 2077, and the latest industrious sniffer on Reddit, BramblexD, has spotted a small snafu with respect to AMD processors. Basically, it isn't utilizing all the logical cores of AMD's chips, just the physical ones—it seems fine on Intel's chips. So, if you've got a 6-core, 12-thread processor, say, Cyberpunk 2077 will only use 6-threads. This could be holding back your performance quite a bit, so it's worth checking.
The easiest way to check this is to open up the Task Manager (right-click the start button and select Task Manager from the list), click more details, and then the Performance tab. Right-click the pretty graph and elect to change the graph to show logical processors as opposed to the default Overall utilization. Now if you launch Cyberpunk 2077 you should see that only half your logical CPU cores are maxed out. Not exactly optimal.
Not only has the problem been spotted, but the community rallied around, and one UnhingedDoork produced a workaround. You'll need to grab a hex-editor, such as the small and perfectly formed HxD which you can grab from here.
Once downloaded, run it and open the main Cyberpunk 2077 executable (which is called Cyberpunk2077.exe for sanity reasons), which you'll find by default in the following folders:
C:\Program Files (x86)\GOG Galaxy\Games\Cyberpunk 2077\bin\x64\
C:\Program Files (x86)\Steam\steamapps\common\Cyberpunk 2077\bin\x64
Hit Ctrl+F once the file has been opened to perform a search, click on the Hex-values tab and enter:
75 30 33 C9 B8 01 00 00 00 0F A2 8B C8 C1 F9 08
Click on that first character, the 75, and change it to EB (it'll turn red to show that you've changed it). Then save the changes.
Now when you run Cyberpunk 2077 you should see that your thread usage is a lot healthier. Depending on your chip you could also see a reasonable uplift in performance. On my test rig packing an AMD Ryzen 5 5600X (6 core, 12 thread) and a GeForce RTX 3080, I went from an average 70 fps before the tweak up to 86 fps, which is a 23 percent improvement. All for a few minutes of work.
We assume this fix will be rolled into the main code at some point, as changing one byte can't be that hard to implement. Given there are plenty of patches planned, it may be worth keeping a vague eye on thread usage with each patch to see if it creeps back in again.