There is literal evidence of shitty coding practices in the OP of this article. It's not FUD at this point, it's a question of how deep the rabbit hole goes.
You SHOULD be asking yourself how much "fine wine" could be gained by fixing all the sure-to-be-found similar crap in the driver. It could be extraordinary.
Like I argued in
#40, the problem Wizz found here is just a symptom of something bigger, the tip of the ice berg if you will. In terms of debugging, we are actually "lucky" when bugs cause consistent stalls or crashes, those are easy to attach a debugger and find, and
should be found by AMD if they did proper testing. Most synchronization issues are often much harder to reproduce consistently, and often disappear when you attach a debugger.
I disagree about AMD just fixing similar crap and getting extraordinary results. Don't get me wrong,
every bug should be fixed, but the inconsistent reliability issues I've seen over many years with AMD drivers tells me there is probably some larger "design flaw". If this was easily fixable, AMD would have fixed it a long time ago.
Me too. My experience (and attempt to help others) with the 5700 XT is well documented here on the forums. In particular, DX11 cpu overhead is absurd.
Perhaps the overhead is "absurd" if you make an isolated test case, but it's not absurd in practice.
Nevertheless, AMD could easily do what Nvidia did, by bringing most of the driver side improvements of DirectX 12 to 11, but that would ruin the image of AMD being better at DirectX 12 though.
With all due respect, no commercial programmer should make a mistake like this ever. It's... I guess you just have to be a programmer to understand. It's like trying to hard boil an egg without water. It shows you have no business in the kitchen.
Really?
Have you worked at code bases of 100.000s or millions of lines of code, possibly with an awful complex structure?
Keep in mind that we are talking about a minor "glitch" here, which could be either a careless mistake or even the result of a bad merge. All programmers do small mistakes, and I'll be the first one to admit doing some embarrassing ones, but what really shows programming skills (or lack thereof) is
how problems are solved, not a tiny mistake. And I mean no disrespect here, but having such attitudes as an engineer is not healthy.
One of the bigger problems I've had in development teams over the years is that lesser coders don't dare to challenge my work, even when I've strongly encouraged them to try to break it. So getting good QA can sometimes be challenging.
Evidence of a mistake, yes. However, the problem that exists strikes me as one that is fairly complicated and not something that could have been anticipated as a potential issue. This was an honest mistake much like the ones Intel, NVidia, Apple, Google, Microsoft, Adobe, etc, etc have made. Computer code is extremely complicated. People really need to stop making mountains out of mole-hills.
Mostly true, yes.
But regarding anticipating issues; all such software projects should have routines designed to validate that a release is working reasonably well. While I don't expect anyone to never make a bug, it is astonishing that they didn't test if the driver behaved erratically in a system with a different GPU present, this
should certainly be in their test suite.
Edit: Let me take another example; some years ago AMD managed to ship two drivers in a row, both failing to compile most GLSL shaders, even basic ones. I still don't understand how it's "possible" to ship a driver without validating basic stuff like this.
What am I missing here?
@Wizzard you forgot to remove the driver and the software before pulling the gfx card or the coding in the associated driver application is crap. YOU as the user are always supposed to uninstall driver...!!! This WHOLE article could have been condensed down a single line -
"When removing a gfx card remember to always uninstall the driver & associated application, if that doesn't work, use DDU. "
This nonsense has been debunked several times, there are many reasons to have different GPUs present, such as;
APU + GPU
Developers or other engineers having multiple GPUs for various compute and simulations
Even APIs like DirectX 12 and Vulkan is designed to work with multiple GPUs from different makes. There is simply no excuse when a driver suite don't handle this.