Please beware, New World MMO beta can cause permanent damage to GPU

Just got my new 3090 build a couple of days ago and now i'm reading about this; its not good for my heart!

Seriously though, what stuff can I do to try and make a bricking as unlikely as possible?

I mean, i'm not touching new world with a bargepole but Anno 1800 is my bag.

Is putting Vsync on in games enough? Should I go into geforce control panel and find the max frames setting instead? Do both?

Can someone calm an old man down? :p
3d0f3d7cc49a83a07561e5cbb81e38ee.jpg
phew there u go carm now ? ;)

I think limiting your max fps to your monitors max refresh rate is the way to go
 

loso64

Well-known member
Just got my new 3090 build a couple of days ago and now i'm reading about this; its not good for my heart!

Seriously though, what stuff can I do to try and make a bricking as unlikely as possible?

I mean, i'm not touching new world with a bargepole but Anno 1800 is my bag.

Is putting Vsync on in games enough? Should I go into geforce control panel and find the max frames setting instead? Do both?

Can someone calm an old man down? :p
to prevent the bricking, make sure you have FPS cap on, either globally via RivaTuner or using ingame cap or turning on VSYNC
 

ubuysa

The BSOD Doctor
FWIW I've passed this on to PCS via the moderator's backchannel. It seems utterly bonkers to me that hardware can be damaged by commercial software.
 

Rakk

The Awesome
Moderator
Just got my new 3090 build a couple of days ago and now i'm reading about this; its not good for my heart!

Seriously though, what stuff can I do to try and make a bricking as unlikely as possible?

One thing II will say though is that its appeared to be EVGA cards that were mostly effected (not sure if PCS ever even supplied any of those anyway - afaik they don't noramlly), and EVGA have been organising RMA's for their broken cards very quickly, and it also looks like Amazon have made a fix as well, so do not panic
 

loso64

Well-known member
One thing II will say though is that its appeared to be EVGA cards that were mostly effected (not sure if PCS ever even supplied any of those anyway - afaik they don't noramlly), and EVGA have been organising RMA's for their broken cards very quickly, and it also looks like Amazon have made a fix as well, so do not panic
there was super limited few amount of EVGA cards month or so, like less than 20
 

ubuysa

The BSOD Doctor
Further to this, I've had a reply from the PCS Support Team (in reply to my earlier moderator backchannel report to PCS). The main content says this...

We would follow the standard returns procedure if any card sold to a customer or in a build was affected or needing to be returned faulty. I have passed this onto our technical manager in case he was not aware already as it is something to hold onto for future reference - as I understand EVGA in retail are working directly with customers to replace, hopefully they are doing advanced replacements.

We have had a larger allocation of 3070Ti cards from EVGA (XC3) recently but my understanding is that we haven’t had any other SKUs from EVGA.

IMO the normal use of commercial software cannot be construed as negligence on the end user's part should the software break your hardware. In that case (and again IMO) PCS would be obliged to replace your graphics card since it has failed through no fault of the end user.

That said however, this thread started because the New World beta was allegedly damaging EVGA 3090 cards. It could be argued that a beta version of software is 'use at your own risk' and I could imagine that damaging your hardware through running a beta version of software could perhaps be classed as negligence?

I would suggest therefore that where the New World beta version (or any beta version) is concerned, FPS caps are the sensible way to protect yourself. :)
 

SpyderTracks

We love you Ukraine
not good, but explained brilliantly as ever, and no punches pulled
One surprise was his summarisation of how dreadful Gigabyte RMA's were, I'm not sure if that's a geographical issue related to the States in particular, but I've preferenced Gigabyte GPU's and motherboards for some time because of how good their RMA service was. Maybe things have changed, must admit, I've not had to RMA anything for a long time, and moved to Asus boards on the last build.
 

ubuysa

The BSOD Doctor
The first time I saw this issue (with the Beta) I didn't really pay much attention - because I'm not a gamer. But I've just watched that video right through and despite what he says - and this is based on my 30 years in the computing industry and probably 40 years messing around with microprocessors, computers, and writing code in several high and low level languages - I am absolutely convinced that there is no way that software can break hardware. Ok, I'll qualify that; there is no way that software should be able to break hardware.

I could for example write some code that executes those instructions that generate the most heat in a CPU or GPU over and over again in a tight loop and the CPU/GPU should be able to handle it. If it can't then the CPU/GPU is not fit for purpose. It's like buying a Ferrari and the dealer telling you that you can't do more than 150mph because the tyres will shred.

If you're in the business of making programmable hardware then you have a responsibility to ensure that it is able to handle the most extreme set of instructions, executed repeatedly over long periods, without failing. It's frankly absurd in my view to blame the algorithm used and inefficiencies in the way the game is coded (the 1+1+1 to get 50 example). It is irrelevant how badly coded the software might be - the hardware should be able to handle any combination of instructions thrown at it.

This feels like a hardware design flaw, as though the designer's brief was to spend the absolute minimum they could get away with on the card(s) so that most instructions in the instruction set could be executed in any order most of the time. Instead, they really should have been designing cards that could handle any instructions in the instructions set executed in any order all of the time. This is going to turn out to be a costing decision, based on what does it cost us to build these cards and what is the maximum sale price we can get away with. It may be that to build cards robust enough to execute any mix of instructions all of the time would make them too expensive for their customer base.

This is flat out a hardware problem. Blaming the software is a cop out. It's like saying that guns don't kill people, people kill people - when clearly the gun is the problem.

On the other hand of course - I like to try and see both sides of an argument - most games don't drive the CPU/GPU hard to enough to reveal these design flaws, so are we building a card for the majority at a price that everyone can afford and which will have problems in certain situations, or are we building a card for every conceivable combination of instructions that only a few can afford?
 

Bhuna50

Author Level
Silly question sorry but isn’t stress testing and even benchmarking software written to push processors to the extreme to see what the best performance you can get is?

As such, how come a game “breaks” it but not a benchmark or stress test program?


Sent from my iPhone using Tapatalk
 

SpyderTracks

We love you Ukraine
Silly question sorry but isn’t stress testing and even benchmarking software written to push processors to the extreme to see what the best performance you can get is?

As such, how come a game “breaks” it but not a benchmark or stress test program?


Sent from my iPhone using Tapatalk
That's what he's saying though, Furmark was so well known for causing gpu failures that running it would void your warranty on the gpu for a long time. So that's what furmark became famous for was highlighting poor gpu cards.

Certain programs push an unreasonable load, that you'd never find in any real world use.

He's not saying its not a hardware issue, what he's saying is that it's highlighting flaws in various gpus, but that it's Amazons responsibility to mitigate that, as well as rhe hardware manufacturers to do better on the next model. But they need to liaise to best provide a solution.

It's a bit like finding a flaw in CPU architecture, you don't simply blame the CPU, bugs are always going to be exposed at some point, there's no such thing as perfect hardware or software, everyone clubs together, they write mitigations at a windows level, microarchitecture level and driver level.

That's exactly what's needed here. Amazon need to let the GPU manufacturers and Microsofts DirectX team and AMD's Vulcan team know how the exploit was realised, and then work with them to write it out at the API level, driver level with nVidia and AMD and at the Game level.

Then hardware manufacturers can understand best how to address the problem in later GPU architectures.

At the moment Amazon are just saying it's not their problem and not communicating how it was realised which leaves everyone in the dark and unable to provide protection to the customer base.
 
Last edited:

ubuysa

The BSOD Doctor
Certain programs push an unreasonable load, that you'd never find in any real world use.
Who is to say what 'real world' use is? Whilst it's unreasonable to use a graphics card as a hammer and you should expect it to break if you do, any graphics card should be able to execute any combination of it's own instruction set and for any length of time. You simply can't say that instructions X, Y, and Z cannot be executed sequentially (for example) or the card will break. If that scenario is thought unlikely to ever happen but catastrophic if it does, then the graphics card should not permit the execution of instructions X, Y and Z internally. It should fail safe.

He's not saying its not a hardware issue, what he's saying is that it's highlighting flaws in various gpus
In blaming the allegedly inefficient code (the 1+1+1 to get 50 example) he's saying that if the code had been more efficient the 'flaw' would not have been revealed. My argument is that if any product can be used in some legitimate way that will break it then the product should protect itself from that legitimate use internally. It should not just break - whether the legitimate use is 'real world' or not.
 

SpyderTracks

We love you Ukraine
In blaming the allegedly inefficient code (the 1+1+1 to get 50 example) he's saying that if the code had been more efficient the 'flaw' would not have been revealed. My argument is that if any product can be used in some legitimate way that will break it then the product should protect itself from that legitimate use internally. It should not just break - whether the legitimate use is 'real world' or not.
I don't think anyone is arguing that, but in the real world, bugs are found on a daily basis. It's about how those bugs are addressed and it takes cooperation from all parties.

At the moment amazon are not doing their due diligence in working to mitigate the issue. That's the only area where amazon are being blamed.
 

ubuysa

The BSOD Doctor
I don't think anyone is arguing that, but in the real world, bugs are found on a daily basis. It's about how those bugs are addressed and it takes cooperation from all parties.
A software bug is a purely software issue. It should simply not be possible to execute any code that breaks hardware. Developers debugging software should never have to worry about whether the bug might damage hardware.

There is a big distinction between software and hardware that the video above seems to deliberately try to muddle - perhaps because those involved are trying to muddle it.

If you build a processor (CPU/GPU or whatever) that has a published set of instructions then I should be able to execute any and all of those instructions in my software without being in the slightest bit concerned about how they might affect the hardware.
 

SpyderTracks

We love you Ukraine
A software bug is a purely software issue. It should simply not be possible to execute any code that breaks hardware. Developers debugging software should never have to worry about whether the bug might damage hardware.

There is a big distinction between software and hardware that the video above seems to deliberately try to muddle - perhaps because those involved are trying to muddle it.

If you build a processor (CPU/GPU or whatever) that has a published set of instructions then I should be able to execute any and all of those instructions in my software without being in the slightest bit concerned about how they might affect the hardware.
Again, that's not being argued.

But the point is these flaws are found every day in hardware at various levels, weather it's CPU's, networking equipment, doesn't matter, and mitigations have to be written at a software level to prevent those exposed flaws from being executed.

It's just the reality of any bug, hardware or software.
 
Top