News Outpost: Infinity Siege' devs ask 13900K, 14900K owners to downclock their chips to prevent crashing

[thestryker]

Then it's a game problem (game engine= game) not hardware rather the way it acts with that game engine.

EDIT everybody knows most board makers are to aggressive with the PL limits. Your average user knows nothing about that but more advanced users know how to adjust it.

Riddle me this: if there's a problem that crops up on fairly small percentage of a specific type of hardware and the resolution is getting the power limits under control how is it software?

 

[bit_user]

Then it's a game problem (game engine= game) not hardware rather the way it acts with that game engine.

If the hardware is causing the game to crash, it's a hardware problem. The way you can tell is that if the game reliably crashes at the same point and adjusting the hardware settings no longer causes the game to crash at that point, then probably it was the hardware.

The first paragraph on the page, says they know it's a game problem and trying to give people a Band-Aid to fix the game until they can.

Nope, that doesn't mean it's a game problem, because even hardware problems can have software mitigations. Most likely, that's exactly what they're working on.

Again, if downclocking your CPU avoids the crash, it's a hardware problem.

 

[Zerk2012]

If the hardware is causing the game to crash, it's a hardware problem. The way you can tell is that if the game reliably crashes at the same point and adjusting the hardware settings no longer causes the game to crash at that point, then probably it was the hardware.


Nope, that doesn't mean it's a game problem, because even hardware problems can have software mitigations. Most likely, that's exactly what they're working on.

Again, if downclocking your CPU avoids the crash, it's a hardware problem.

You can say anything you wish but this still says it all!!!!!!!!!!!
Still trying to patch the problem!!!!!!!!!!!!
URE5 is just crap!!!!!

Recently released title Outpost: Infinity Siege just got its second patch in a matter of days rectifying certain crashes during cutscenes. However, the developerss revealed in the patch notes that there are still high-priority issues causing severe crashes and screen blackouts in-game. The issues are bad enough that the developers at Team Ranger are recommending users downclock their Core i9 Raptor Lake or Raptor Lake Refresh CPUs to 5 GHz as a temporary measure.

That says game problem.
CPUs to 5 GHz as a temporary measure.
CPUs to 5 GHz as a temporary measure.
CPUs to 5 GHz as a temporary measure.

 

[bit_user]

You can say anything you wish but this still says it all!!!!!!!!!!!
Their still trying to patch the problem!!!!!!!!!!!!

A good analogy is the security bugs that have come to light, like Specter and Meltdown. These are actual hardware bugs, but they can be mitigated in software. Therefore. the potential for a software patch doesn't necessarily make it a software bug.

That says game problem.

If downclocking i9 CPUs is actually causing them not to crash, then it is actually a hardware problem! The reason the game is triggering it is just because it's spiking the CPU utilization high enough. I'm sure the way they're going to address it is simply by reducing the number of cores used by the game. That's not a fix, but rather a mitigation (i.e. workaround) of the hardware issue.

By your logic, Prime95 is buggy because it can cause an overclocked machine to crash. No, just because a piece of software can stress your hardware to the point of malfunction doesn't make it the software's fault.

 

[Zerk2012]

A good analogy is the security bugs that have come to light, like Specter and Meltdown. These are actual hardware bugs, but they can be mitigated in software. Therefore. the potential for a software patch doesn't necessarily make it a software bug.


If downclocking i9 CPUs is actually causing them not to crash, then it is actually a hardware problem! The reason the game is triggering it is just because it's spiking the CPU utilization high enough. I'm sure the way they're going to address it is simply by reducing the number of cores used by the game. That's not a fix, but rather a mitigation (i.e. workaround) of the hardware issue.

Has anybody said it fixed the issue? NO none I have seen.

Down clocking a processor to fix a game issue is a stupid suggestion how in the world does clock speed crash a game that is not broke?


Again from their post.

CPUs to 5 GHz as a temporary measure.

as a temporary measure.

Does this not say they are trying to fix it or not LOL!!!!!!!!!!!!!!!!!!!!!!!!!!

as a temporary measure.

To me that says we have a problem and are trying to work on it. Just like the patches coming out very often. = rushed out game using a very poor game engine just to start making money.

EDIT that was my last post on this it's clear you wish to make it a Intel problem when it's a game/game engine problem.

 

[bit_user]

Has anybody said it fixed the issue? NO none I have seen.

Agreed. It would be good to get some confirmation of this.

Down clocking a processor to fix a game issue is a stupid suggestion how in the world does clock speed crash a game that is not broke?

I'd recommend reviewing this comment thread, for further discussion of the issue:

News - Is your Intel Core i9-13900K crashing in games? Your motherboard BIOS settings may be to blame — other high-end Intel CPUs also affected

Gamers and game developers are taking note of crashes on high-end Intel CPUs, and we think we have the answer. Multiple answers, even. Power, current, voltage, and clock speeds are all potential factors. Is your Intel Core i9-13900K crashing in games? Your motherboard BIOS settings may be to...

forums.tomshardware.com

Note that a more recent article has been published, where undervolting + disabling CEP are recommended by MSI as a workaround:

https://www.tomshardware.com/pc-com...mmends-disabling-cep#xenforo-comments-3838873
​

Your really sounding like a AMD fanboy.

Nope, non-partisan.

I am a fan of logic and I guess hardware and software which works properly. I have debugged a lot of software, including times when the root cause of the problem was the hardware, the OS, or the compiler. I've developed plenty of workarounds, as well, when fixing the root cause was out of my control.

Again from their post.

I don't know what you're hoping to accomplish by re-posting, but I think it's not productive. I've read it every time you posted it and taken the time to explain why I disagree with your interpretation.

I can accept that you disagree with me. Can you accept the same?

 

[CmdrShepard]

How would intel have this data?

Intel has both their own CPU telemetry collection through windows drivers and I am sure Microsoft is letting them in on all the OS crashes caused by Intel hardware.

You think they validate every CPU at unlimited power with every piece of software under the Sun?

If they aren't, they should be if that's how they sell them.

Apparently, there's an instability in a single-digit percentage of Intel CPUs which leads to incorrect program execution and / or outright crashes.

Whichever way you look at it Intel is responsible because they are selling unlocked chips and endorsing overclocking with their K models -- motherboard manufacturers are just giving users the means to do what Intel allows and their only responsibility is to provide sensible defaults.

Those defaults are in turn driven by comparative benchmarking performed by so many hardware reviewers who leave everything at default settings instead of locking every motherboard and CPU they test to the same sensible settings. They are the ones who enabled motherboard makers to compete for benchmark scores using increasingly more insane default BIOS settings.

Moreover, the majority of users, even those who build their own PCs, almost never enter BIOS and touch any of the default settings. Because why would they? Reviewers tested their review samples at default settings so it must work for them too, right? We all know that's now how any of this works.

Finally, software developers can only do so much if the CPU itself misbehaves.

 

[35below0]

Intel has both their own CPU telemetry collection through windows drivers and I am sure Microsoft is letting them in on all the OS crashes caused by Intel hardware.

If they aren't, they should be if that's how they sell them.

Apparently, there's an instability in a single-digit percentage of Intel CPUs which leads to incorrect program execution and / or outright crashes.

Whichever way you look at it Intel is responsible because they are selling unlocked chips and endorsing overclocking with their K models -- motherboard manufacturers are just giving users the means to do what Intel allows and their only responsibility is to provide sensible defaults.

Those defaults are in turn driven by comparative benchmarking performed by so many hardware reviewers who leave everything at default settings instead of locking every motherboard and CPU they test to the same sensible settings. They are the ones who enabled motherboard makers to compete for benchmark scores using increasingly more insane default BIOS settings.

Moreover, the majority of users, even those who build their own PCs, almost never enter BIOS and touch any of the default settings. Because why would they? Reviewers tested their review samples at default settings so it must work for them too, right? We all know that's now how any of this works.

Finally, software developers can only do so much if the CPU itself misbehaves.

I would agree with you but publishers are responsible for releasing tested and stable software (games), and 9 times out of 10 they will set insane deadlines that developers cannot meet if they carry out a reasonable amount of testing . Partly because there are so many hardware combinations to test.

It is publishers who are to blame much more than intel or even motherboard manufacturers.
Most games released today will be stable enough to only require some patches and fixes for things developers could not be expected to catch.
Other games are flat out rushed out the door come hell or high water.

 

[CmdrShepard]

I would agree with you but publishers are responsible for releasing tested and stable software (games), and 9 times out of 10 they will set insane deadlines that developers cannot meet if they carry out a reasonable amount of testing . Partly because there are so many hardware combinations to test.

It is publishers who are to blame much more than intel or even motherboard manufacturers.
Most games released today will be stable enough to only require some patches and fixes for things developers could not be expected to catch.
Other games are flat out rushed out the door come hell or high water.

I think there's enough blame to go around for both of these things to be true.

However, I still think Intel is more responsible.

On a side note, I have a workstation with Sapphire Rapids Xeon CPU. SPR has new instructions called AMX which only works in Windows 11. I've had issues with Visual Studio debugger failing misteriously to step through the code but working when I disable AMX or when I try debugging the same thing under Windows 10 where AMX is not supported.

Who's to blame? Obvious choice is Microsoft because they wrote Visual Studio. But when you report the issue they say "We have no workstations with SPR CPU and can't reproduce your issue".

So who's to blame then? Intel of course. When you release a CPU which requires changes to the way how OS and debugger work then you make damn sure that vendors writing those get your support to implement and test it properly.

 

[bit_user]

I would agree with you but publishers are responsible for releasing tested and stable software (games),

Their testing is for bugs in the software they make. They don't do enough testing (nor can they be expected to), in order to turn up hardware problems. However, I'm sure it happens that they trip over the occasional GPU/driver bug.

It is publishers who are to blame much more than intel or even motherboard manufacturers.

Given it's not like we even have an established precedent for game crashes by mainstream CPU/motherboard models, why would they even devote time or resources to looking for them? Not least of all, if the crash only happens for a minority of users with a given setup! That means you need several copies of each hardware config and that quickly gets very expensive!

Blaming this on game publishers is like blaming an automobile defect on car reviewers for missing it. No, if the defect is in the hardware, the blame lies with them. They need to test their products and model the degradation curves well enough to know what are the safe & supportable limits. For failing to do that, I hope they get swamped with warranty claims.

Most games released today will be stable enough to only require some patches and fixes for things developers could not be expected to catch.
Other games are flat out rushed out the door come hell or high water.

I'm not defending game development houses for genuine software bugs, mind you. I think there's plenty of legit criticism that can be directed towards that industry.

 

[bit_user]

I have a workstation with Sapphire Rapids Xeon CPU. SPR has new instructions called AMX which only works in Windows 11. I've had issues with Visual Studio debugger failing misteriously to step through the code but working when I disable AMX or when I try debugging the same thing under Windows 10 where AMX is not supported.

Who's to blame? Obvious choice is Microsoft because they wrote Visual Studio. But when you report the issue they say "We have no workstations with SPR CPU and can't reproduce your issue".

You have to ask whether Visual Studio is supported on your hardware, and if the answer is "yes", then it should be incumbent on them to fix it. The only way I see MS getting let off the hook is if their platform support clearly excludes the class of machines you're running on.

BTW, an entry level SPR workstation doesn't even cost that much. More than a mainstream desktop, but you can get those things with as few as 6 cores. IMO, they have no good excuse not to procure the hardware if they lack it. I'd make a stink about it on Intel's developer forums, if I were you.

So who's to blame then? Intel of course. When you release a CPU which requires changes to the way how OS and debugger work then you make damn sure that vendors writing those get your support to implement and test it properly.

That might be true, but maybe not. To reach that conclusion, we need to know whether Intel actually did change anything about the way debugging works, or if maybe the Visual Studio debugger is just choking on those instruction opcodes in the binary. If debugging was actually impacted by AMX, we'd also need to know whether Intel published the requisite information and Microsoft ignored it.

 

[CmdrShepard]

You have to ask whether Visual Studio is supported on your hardware, and if the answer is "yes", then it should be incumbent on them to fix it.

They don't say it isn't:
https://learn.microsoft.com/en-us/visualstudio/releases/2022/system-requirements

BTW, an entry level SPR workstation doesn't even cost that much.

I know, that's why I have built myself a workstation with W5-2455X.

IMO, they have no good excuse not to procure the hardware if they lack it.

Or just borrow it from someone in the OS division.

I'd make a stink about it on Intel's developer forums, if I were you.

I will try that too, because it's really annoying.

That might be true, but maybe not. To reach that conclusion, we need to know whether Intel actually did change anything about the way debugging works, or if maybe the Visual Studio debugger is just choking on those instruction opcodes in the binary. If debugging was actually impacted by AMX, we'd also need to know whether Intel published the requisite information and Microsoft ignored it.

What AMX changes when it's enabled is the XSAVE/XRESTORE thread state size.

This affects the OS context switching as well and AMX requires OS support to be enabled which Windows 11 already has.

However, it seems the VS debugger under some unspecified conditions chokes on this increased thread state size and says there's no code to debug. I am sure it's AMX because if I disable it in system BIOS the same project which I couldn't debug now debugs just fine without any other changes.

 

[bit_user]

I know, that's why I have built myself a workstation with W5-2455X.

Nice! What CPU cooler & motherboard?

What AMX changes when it's enabled is the XSAVE/XRESTORE thread state size.

This affects the OS context switching as well and AMX requires OS support to be enabled which Windows 11 already has.

However, it seems the VS debugger under some unspecified conditions chokes on this increased thread state size and says there's no code to debug. I am sure it's AMX because if I disable it in system BIOS the same project which I couldn't debug now debugs just fine without any other changes.

Oh, so you're saying that your program doesn't even need to include any AMX instructions, in order for the debugger to fail? That's wild!

BTW, I'd like to see the registers window for inspecting the AMX state!
: D

 

[CmdrShepard]

Nice! What CPU cooler & motherboard?

Noctua NH-U14S DX-4677 and Supermicro X13SRA-TF. The things I regret about the board is that BIOS is damn slow to initialize PCIe devices, lacks fan control (it's done by BMC which isn't "certified" with low RPM fans), and that you need to boot UEFI shell to flash BIOS updates.

Oh, so you're saying that your program doesn't even need to include any AMX instructions, in order for the debugger to fail? That's wild!

Yes, and it somehow only affects debugging of x86 native or mixed (C++/CLR) code. Debugging other stuff works.

BTW, I'd like to see the registers window for inspecting the AMX state!
: D

You might need a 21:9 monitor just for that.

 

[bit_user]

Noctua NH-U14S DX-4677 and Supermicro X13SRA-TF. The things I regret about the board is that BIOS is damn slow to initialize PCIe devices, lacks fan control (it's done by BMC which isn't "certified" with low RPM fans), and that you need to boot UEFI shell to flash BIOS updates.

Sometimes, the BIOS menus give you options to disable features you're not using, which can then speed up boot times. Also, in my limited experience, boards with BMC tend to have longer boot times. That's a major reason I'm going with a non-BMC board, for my next workstation.

Also, when looking at some Supermicro boards, they don't seem to go above initial manufacturer stock values. For instance, the X13SAE is limited to DDR5-4400, even though it supports up to 14th gen CPUs, which allow much faster memory than that.

https://www.supermicro.com/en/products/motherboard/X13SAE
​

By contrast, the ASUS Pro WS W680-ACE supports up to DDR5-5600.

Pro WS W680-ACE｜Motherboards｜ASUS Global

Intel® W680 LGA 1700 ATX motherboard, DDR5, PCIe 5.0, 2.5 Gb, SlimSAS, enhanced power and cooling solutions

www.asus.com

 

[CmdrShepard]

Sometimes, the BIOS menus give you options to disable features you're not using, which can then speed up boot times.

I am aware of that, but in this instance their support response is that I am using "non-certified" hardware with it like consumer Samsung M.2 drives (Pro series), ASUS RTX 4090, and ASUS M.2 PCIe card. They only have enterprise hardware on their QVL. I am aware that excuse is bullshit, but there's nothing I can do now.

Also, in my limited experience, boards with BMC tend to have longer boot times. That's a major reason I'm going with a non-BMC board, for my next workstation.

Aware of that too, but BMC init can go in parallel, no need to slow down boot and I also checked by post code (92 is PCI bus init and it's the one that takes forever during boot).

Also, when looking at some Supermicro boards, they don't seem to go above initial manufacturer stock values. For instance, the X13SAE is limited to DDR5-4400, even though it supports up to 14th gen CPUs, which allow much faster memory than that.

The boards themselves should not add or remove any limits, memory speed available should depend on the CPU you stick in it.

That said, I usually buy ASUS stuff, but their 790 boards are really overwhelmed with unnecessary stuff. Like, 8x USB 2.0 ports, really? Not to mention physical layout of the PCIe slots and location of M.2 are worse. This Supermicro board has perfect layout and features, the only problem is that Supermicro is extremely consumer-unfriendly.

 

[NinoPino]

Down clocking a processor to fix a game issue is a stupid suggestion how in the world does clock speed crash a game that is not broke?

Instead, this is not only an intelligent suggestion but also the only thing to isolate the real software problems.
Have you ever tried to debug a crashing software running on an instable system ?
It is simply impossible.

Again from their post.

CPUs to 5 GHz as a temporary measure.

as a temporary measure.

Does this not say they are trying to fix it or not LOL!!!!!!!!!!!!!!!!!!!!!!!!!!

as a temporary measure.

To me that says we have a problem and are trying to work on it. Just like the patches coming out very often. = rushed out game using a very poor game engine just to start making money.

For sure they are trying to fix software problems but they at the same time they NEED to exclude bug reports from peoples with instable systems. To do so, the most simple and reliable thing to say is to downclock the CPU to 5Ghz.
Once they addressed all the bugs than they will give instructions to raise the clock speed again and the remaining instability will due to systems.

For the developers, this is only a debug methodology, not an accusation on Intel's CPU problems.

EDIT that was my last post on this it's clear you wish to make it a Intel problem when it's a game/game engine problem.

As you wish.

 

[bit_user]

This Supermicro board has perfect layout and features, the only problem is that Supermicro is extremely consumer-unfriendly.

One superficial thing I like about Supermicro is how some of their boards are still that good 'ol utilitarian green. I'd almost wear it as a point of pride not only to have a board with no RGB or gamer bling, but even for its PCB to sport that familiar color.