News Cyberpunk 2077 Bug Bulldozes AMD Ryzen: Here's a Fix, Tested

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Doesn't make the slightest bit of different on my 5900x and RTX3080 system.
Then again the article does say over 8 cores doesn't seem to do much, in some cases lose performance, so just in case I'm going to set the exe back to stock.
This makes it sound like to me that since they had to support the PS4 and XB1, they made sure it could work with 8 cores, but it slipped their minds SMT was a thing. Considering work on the game started in 2012 and the foundations of the core engine were likely set in stone a few years after that, I'd just chalk this up to "oops, forgot that existed"
 
Maybe this is the ymmv have setup game and 72fps 1440p. Not turn down settings too much I dont feel. 30-40% cpu usage then did hex fix goes to 20-50% so something changed and I lose 5 fps. No conclusion other than this no help performance for me. So not play too long maybe 6hrs but no crash so far game runs smooth and looks good. This on the AMD card so no rtx yet. Does this feel like maybe nvidia pressure for rtx release?
 
Last edited:
Doesn't make the slightest bit of different on my 5900x and RTX3080 system.
Then again the article does say over 8 cores doesn't seem to do much, in some cases lose performance, so just in case I'm going to set the exe back to stock.

Isn’t your system fast enough already? 😉
 
As a 3900X owner, this bug concerns me. This is yet another reason to wait 3-9 months to play Cyberpunk once it's actually complete and performing well. Having employees crunch to complete a game results in all sorts of small bugs like this. There's probably all sorts of things coded into the game but disabled at the moment because of the rush to release.

Besides, I'm not entirely sure a 1070 GPU is going to provide a good enough experience. Maybe a 6800 or 3070 will, but who knows when they'll actually be in stock again.

As it was explained, this "bug" seems to affect Ryzen CPU but, the biggest hit goes to the lower core count models. A Ryzen 2600/3600/5600 (" "/X/XT) with only 6 physical cores and 12 threads may be impacted, depending on the resolution and GPU paired with.

Now a Ryzen 9 3900 with 12 physical cores and 24 threads should not be impacted because you already have more physical cores than what the game seems to be able to use.
 
Last edited:
  • Like
Reactions: geogan
Ok, so noob question. If you suspected another game (looking at you Ubisoft) can you try this hex editor fix on another game?
I would think not as this is specific per game.
 
Ok, so noob question. If you suspected another game (looking at you Ubisoft) can you try this hex editor fix on another game?
I would think not as this is specific per game.
Only if they were artificially limiting how many threads to spawn by looking for specific CPUs by their CPUID tag. This isn't going to say, make a game that seems to cap out at 4 threads go to 8. That's a design problem.
 
  • Like
Reactions: Dewey72
Because they have a vested interest in ensuring their hardware doesn't look inferior.
How were to know that the studio was using old code? Are they to make sure every game studio is using the correct code? Seems like it should be on the game designers to make sure it's correct and their game plays properly on all available(especially current) hardware. IMO

It's not up to fuel companies to make sure engine designers build engines that run on available fuel.
 
Last edited:
I was curious what exactly this fix is doing, so I compared the values they said what to look for vs what to change. Funnily enough, it's a single byte:
Code:
75 30 33 C9 B8 01 00 00 00 0F A2 8B C8 C1 F9 08
EB 30 33 C9 B8 01 00 00 00 0F A2 8B C8 C1 F9 08
The first byte (the two hex digits) is the only thing different. This makes me think all the changed was an opcode. Curious I was wondering from which to which, and what I can gather from a listing on Wikipedia, the closest matches I could find are:
  • PCMPEQW xmm1, xmm2/m12866 0F 75 /rCompare packed words for equality.

  • POR xmm1, xmm2/m12866 0F EB /rBitwise OR
Looking up these instructions, the first one compares a bunch of bytes in one place to a bunch of bytes of another. If they match, it sets all of the bytes in the first bunch of bytes to 0xFF (or a bit-wise 1 fill), 0 otherwise. The second does a bitwise OR operation on one bunch of bytes with another and stores the result in first bunch of bytes. My guess is the next instruction in the slot is "are the bunch of bytes we compared not all 0?" or something similar. If it's that, then doing a bitwise OR beforehand will always result in a pass because what's being looked for isn't all 0's and no production CPU is going to have all 0's in its CPUID fields.

The choice of using an SSE instruction makes me scratch my head a little, but I guess they're being specific about what to look for and maybe it's faster to do a vector operation on it.

Note that I haven't looked at the actual executable with a hex editor to verify if the two bytes before what they said to change is 66 0F. I'm just bored.

EDIT: to put this in a programming language or something, the change is something like this
Code:
if (cpuid == "bulldozer")

to

Code:
if (cpuid | "bulldozer")

This will always pass.
 
  • Like
Reactions: JarredWaltonGPU
I was curious what exactly this fix is doing, so I compared the values they said what to look for vs what to change. Funnily enough, it's a single byte:
Code:
75 30 33 C9 B8 01 00 00 00 0F A2 8B C8 C1 F9 08
EB 30 33 C9 B8 01 00 00 00 0F A2 8B C8 C1 F9 08
The first byte (the two hex digits) is the only thing different. This makes me think all the changed was an opcode. Curious I was wondering from which to which, and what I can gather from a listing on Wikipedia, the closest matches I could find are:
  • PCMPEQW xmm1, xmm2/m12866 0F 75 /rCompare packed words for equality.

  • POR xmm1, xmm2/m12866 0F EB /rBitwise OR
Looking up these instructions, the first one compares a bunch of bytes in one place to a bunch of bytes of another. If they match, it sets all of the bytes in the first bunch of bytes to 0xFF (or a bit-wise 1 fill), 0 otherwise. The second does a bitwise OR operation on one bunch of bytes with another and stores the result in first bunch of bytes. My guess is the next instruction in the slot is "are the bunch of bytes we compared not all 0?" or something similar. If it's that, then doing a bitwise OR beforehand will always result in a pass because what's being looked for isn't all 0's and no production CPU is going to have all 0's in its CPUID fields.

The choice of using an SSE instruction makes me scratch my head a little, but I guess they're being specific about what to look for and maybe it's faster to do a vector operation on it.

Note that I haven't looked at the actual executable with a hex editor to verify if the two bytes before what they said to change is 66 0F. I'm just bored.

EDIT: to put this in a programming language or something, the change is something like this
Code:
if (cpuid == "bulldozer")

to

Code:
if (cpuid | "bulldozer")

This will always pass.
And still, after all that, it doesn't work!
 
Finding cyberpunks very enjoyable. Storyarc is good. Spend so much time just looking around and enjoying the visuals. It gonna take me forevr to make the max level. Wishes they have the AMD rtx. Guess that will be in future. No crashing other than my car for bad driving.

So they saying mod'ers will help improve fps I not sure how that works? Will have to keep the eyes open. For me I feel game is very playable around 60 fps or higher and that achieveable now. Some others disagree and that ok :)
 
How were to know that the studio was using old code?

If they had tested it, they should have discovered the poor thread scheduling. They may not have known the reason right off the bat, but it would have prompted an investigation.

Seems like it should be on the game designers to make sure it's correct and their game plays properly on all available(especially current) hardware.

Sure, but it's not good business sense to place your brand image in someone else's hands.
 
For those interested, what you are actually doing is changing a JNE (Jump short if not equal) to an unconditional JMP instruction.

That piece of code checks the processor family. If family not equal to 0xf the number of threads is set to the logical cores minus one. The change makes you always jump to this code and set threads to logical cores minus one, instead of going to code that sets the threads to physical cores minus one on (certain?) AMD cpus.

BTW from the code it looks like a Pentium 4 with hyperthreading should also have this issue. Not that anyone would want to play this game on a Netburst CPU anyway :/

For those that can read Dutch or just want to see the assembly code, .oisyn and Memori did the work @ https://tweakers.net/nieuws/175694/...hreads-van-bepaalde-amd-cpus-na-hex-edit.html
 
Has this actually worked for anyone? Or is it just a load of rubbish someone has made up on Reddit?
I mean, it's worked for Tom's considering what they posted. But judging by what we do know:
  • If you already have an 8-core processor, it likely doesn't boost performance all that much
  • It may only affect Ryzen, considering you can identify CPUs by manufacturer then by model.
  • Ultimately performance boosts may depend on your settings and what other hardware you have
 
Have seen mod'ers have been making other discoveries in game files that might give a try but look for more explainations or feedback. Looking good though.
 
Last edited:
I mean, it's worked for Tom's considering what they posted. But judging by what we do know:
  • If you already have an 8-core processor, it likely doesn't boost performance all that much
  • It may only affect Ryzen, considering you can identify CPUs by manufacturer then by model.
  • Ultimately performance boosts may depend on your settings and what other hardware you have
Actually, I think it's only if you have a dual chiplet Ryzen that it doesn't help and may hurt. 5900X and 5950X generally performed better without the 'fix' but the single chiplet 8-core and 6-core chips benefitted, sometimes quite a lot.
 
Sure, but it's not good business sense to place your brand image in someone else's hands.
I don't think CPU manufacturers are typically going around ensuring that upcoming game releases are running optimally on their processors. That should be up to the developers, if they don't want bad word of mouth that will negatively affect the sales of their games. And one would expect a game this high profile, and so long in development, which was delayed multiple times supposedly to make sure it was "perfect" for release, to be relatively well optimized by the time it launches.

I could see graphics hardware companies providing game developers with assistance, especially for new architectures and features like raytracing that may require new techniques to get the most out of them. But the performance characteristics of AMD's Ryzen and Intel's Core processors tend to be reasonably similar for the most part, so one wouldn't expect there to be any huge performance differences between the two. And there shouldn't have been. The only reason we are seeing this issue is that CD Projekt totally failed at adequately testing this game before it went out the door, and allowed a single poorly-designed processor check to cripple performance on some CPUs by needlessly disabling half of the processor's threads. Surely those performance anomalies should have been caught in testing, even without any outside assistance.

If anything, one would have expected the console manufacturers to play a larger role in ensuring optimized performance on their hardware. But the performance there is absolutely abysmal, at least on the devices that most people have, running at upscaled SD resolutions with low graphics settings, but still seeing frame rates often drop below 20 on the base consoles, to the point where the game currently has Metascores in the low 50s on both the Xbox One and PS4. The PC release fared relatively well by comparison.
 
  • Like
Reactions: RodroX