• Please review our updated Terms and Rules here

The New Z170 Motherboards

GiGaBiTe said:
He claims to be using FMA operations in his program, which is the program in question that crashes using FMA operations, and he goes on to explain that other programs that use FMA operations do not crash. This is why I attributed it to user programmer error, or compiler error.
Click to expand...

What if it's neither of those things? The crash could be caused by a design fault in the CPU, something which may or may not be possible to be worked around in software/firmware without a serious performance penalty, or perhaps at all. This is not purely theoretical, it has actually happened in practice in a real-world program which was not specifically designed to misbehave. Luckily there was a pain-free workaround in that case.

Using optimizations for an architecture other than the one you're currently working with is known to cause problems.
Click to expand...

It should never happen in theory and in practice it only happens exceptionally rarely, assuming "problems" doesn't include slowdowns, something which can easily happen, i.e. optimizing for one processor can result in code being inadvertently deoptimized for another. Optimizations which work for one processor should never cause another to crash.
 
I'm an optimist. All the reviews that I've read so far; 'Tom's' and 'The Tech Report' for instance, give the chip pretty good reviews. Wait for some reports from the high-end gamers, as they're usually the first group to cry foul. There's going to be a few bumps in the road, but after all, AMD's butt is on the with this issue and it would be hard to believe that they haven't covered all of the bases. Just my opinion.
 
I just don't see any point in jumping on Ryzen while the BIOSes are being updated multiple times a week. Wait a month or two until most of the issues are confirmed to be fixed.
 
GiGaBiTe said:
Just because two different companies that make CPUs which can conform to a specific instruction set, doesn't mean the registers used, opcode mnemonics, guaranteed execution time or opcode arguments are required to be the same. Only the end result is mostly guaranteed, though not in all cases.
Click to expand...

That's completely wrong. If Intel puts out an instruction that is supposed to perform an operation with a set of inputs, AMD needs to emulate that instruction exactly (meaning, with the same input values, the same output value would be produced as on Intel). If AMD could just make stuff up, programs written for Intel would crash on AMD, and vice versa.

Giving you the benefit of the doubt: If you want to argue that the programmer may have enabled instructions that don't exist on Ryzen, and those instructions are hanging Ryzen, then that is valid and you should make that argument instead.
 
From the Tech Report today . . .

The first major bug affecting AMD's new Ryzen processors was found a couple weeks ago by folks using the open-source processor benchmark Flops. In short, certain sequences of code using instructions from the FMA3 expansion to the x86-64 ISA can cause Ryzen machines to hang irrevocably. That means that even software running inside a VM could force a hang-and-restart on a Ryzen host. Fortunately, just days after the discovery was made, AMD confirmed to Digital Trends that it has already identified the issue and that it's preparing firmware updates to distribute to motherboard vendors.


Originally created by Alexander "Mystical" Yee for his own purposes, Flops first appeared on the web as a response to a question at Stack Overflow. In the creator's own words, the app seeks to "get as many FLOPS as possible from an x64 processor." The software's first version was targeted at Intel Sandy Bridge processors. Mystical eventually updated the app with five specific branches targeting Core 2, Bulldozer, Piledriver, and Haswell CPUs.

It's the Haswell build that gives Ryzen trouble, as it makes heavy use of FMA3 instructions to extract maximum parallelism from the CPU cores. Loading up the Haswell build of Flops v2 on a Ryzen machine will quickly make it hang. Folks on the HWBOT forums leaped into action testing Flops in other scenarios to confirm that the issue is related to the Zen core. As a result, all current Ryzen processors and motherboards are affected.


It's good news that AMD already has a fix coming, although it's worth noting that the likelihood of encountering this bug in the wild is vanishingly small. Not only is there little software using FMA instructions (after all, they're only supported on Haswell and later Intel processors), but the hang is triggered by a specific series of instructions. Other applications using FMA instructions, including Prime95 and Y-Cruncher, aren't affected by the bug. Still, if you have a Ryzen machine, best go ahead and install those BIOS updates when they arrive.

 
Last edited:
The cruft that's been bolted onto the basic x86 architecture is mind-boggling. The x86 architecture itself is basically a bolt-on to x80, which, in turn, is a bolt-on to x08. Good Lord, isn't it time for a really new ISA, say RISC-V? Of course, RISC-V is just a re-tread of 50 year old ISAs.
 
Modern x86 processors are really just x86 emulators. They are actually RISC processors under the hood.
 
Trixter said:
That's completely wrong. If Intel puts out an instruction that is supposed to perform an operation with a set of inputs, AMD needs to emulate that instruction exactly (meaning, with the same input values, the same output value would be produced as on Intel). If AMD could just make stuff up, programs written for Intel would crash on AMD, and vice versa.
Click to expand...

Nope. One example is AMD64 vs Intel's EM64T:

https://jetteroheller.wordpress.com/2007/03/09/whats-the-difference-between-amd64-and-intel-em64t/
https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64

In this case, it was Intel trying to comply with AMD64, which they failed to do completely. Even different generations of CPUs from both manufacturers have varying implementations of 64 bit support, the most common problem being CMPXCHG and how large of a data value the operands support.

In an older reverse situation with AMD trying to implement MMX as 3D Now!, AMD extended the MMX instruction set so it's not quite compatible due to having extended features.

And technically you could include processor bugs like Intel F00F, FDIV and the Cyrix coma bug because they're specific instructions that don't do the same thing on other CPUs.
 
There's a big difference between "attempting to reproduce an instruction exactly but getting it wrong due to mistakes or bugs", and "not even bothering to get it right in the first place". I thought you were trying to argue for the latter point, which I don't accept (there is no point in AMD intentionally screwing up compatibility with Intel CPUs because that would lead to software outright crashing on AMD and obviously they don't want that).
 
You're arguing a point that never existed. It doesn't matter if you don't accept that a company diverged from an ISA because of incompetence, political reasons, enhancements, bugs or some other reason; The end result is the only thing that matters since we have to deal with it.

The fact is that instruction sets from AMD and Intel are not 100% identical, and even the same existing instruction sets within both respective companies vary between generations.

Trixter said:
AMD intentionally screwing up compatibility with Intel CPUs because that would lead to software outright crashing on AMD and obviously they don't want that.
Click to expand...

Why are you assuming that Intel was the creator of all x86 instruction sets? Because they weren't. AMD invented x86_64 as we know it, Intel copied that because their Itanium and Pentium 4 couldn't compete. AMD also had contributions to the various SSE instruction sets, XOP, CVT, FMA and BMI.
 
There are two theories to this story.
Intel claims that the x86-64 specification they received from AMD was not the final one, and therefore what they implemented was not the same as what AMD put to market.
Which could have been a deliberate action from AMD to sabotage Intel.
Of course, it could also be that Intel deliberately made some changes to the specification to try and sabotage AMD (since Intel would easily have the largest marketshare, and therefore would become the de-facto standard, making AMD incompatible with their own extensions. A similar thing happened with JavaScript, where the standardized version was not compatible with the original implementation by Netscape, the originators of JavaScript).
 
Given AMD and Intel's extensive legal and competitive history, I wouldn't doubt they've tried to stab each other in the back more than once.
 
GiGaBiTe said:
You're arguing a point that never existed. It doesn't matter if you don't accept that a company diverged from an ISA because of incompetence, political reasons, enhancements, bugs or some other reason; The end result is the only thing that matters since we have to deal with it.
Click to expand...

I'm not going to buy a processor that claims to be compatible with Intel but isn't. If AMD says Ryzen is 100% compatible with (for example) Broadwell on downward, then it shouldn't crash or hang if I run software that was optimized for Broadwell. It can run that software at any speed, but it needs to run, not hang or crash. Your prior argument was to blame the guy for picking the wrong optimization options for his program not working on Ryzen, and I don't agree with that.

This isn't a matter of (for example) using SSE3 when the CPU only supports SSE2 -- it's a matter of the CPU claiming to support SSE3 but then hanging when SSE3 is used. That cannot be the progammer's fault.
 
GiGaBiTe said:
Given AMD and Intel's extensive legal and competitive history, I wouldn't doubt they've tried to stab each other in the back more than once.
Click to expand...

The whole reason why AMD still makes x86 CPUs today is because of one big backstab to Intel:
IBM demanded that Intel second-source their CPUs, to avoid supply issues (difficult to imagine today... Chipzilla and supply problems? But back then, Intel was not the uber-strong player it is today).
They never renewed the second-source license for the 386, since IBM was no longer relevant in the PC market, and Intel no longer needed them to sell x86 CPUs, and as such they no longer needed to meet any demands from IBM.
So Intel never supplied AMD with the designs and microcode for the 386 either. So, AMD reverse-engineered the 386 themselves, and wanted to sell them. They claimed that the second-source license entitled them the rights not only to 8088 and 286, but future x86 as well. Which is bollocks, obviously.
At which point Intel sued them, and won... more or less. It was ruled that x86 was too important to the industry for Intel to have a monopoly on the instructionset. So Intel was forced to license others to make x86-compatible CPUs.
If it were up to Intel, AMD would never have made x86 CPUs at all... and certainly not after the second-source license ran out.
 
Ryzen only seems to fail on specific patterns of FMA3 instructions. May take AMD some time to figure out the exact fix but problems like this can often be solved with microcode that inserts NOPs to break up the offending sequences.

Ryzen does seem to have been rushed to market. Many minor flaws are being caught with rudimentary testing by purchasers.
 
krebizfan said:
Ryzen does seem to have been rushed to market. Many minor flaws are being caught with rudimentary testing by purchasers.
Click to expand...

The sad thing is that this is the third time in a row...
Bulldozer also had issues causing bluescreens in various software on release, and required a BIOS upgrade. The devil is in the details: Bulldozer was originally planned to be a drop-in upgrade for a variety of boards/chipsets. At release, AMD only officially supported the 990 chipset. However, many boards had been sold as "Bulldozer-compatible" during that time, many of them using other chipsets.
Since Bulldozer was so late, various of these boards were even EOL, so only a small number of boards (and only with the 990 chipset) ever received the BIOS upgrade to fix the issue. All the people who bought a board in advance, hoping to upgrade from a Phenom to a Bulldozer once it was released, were left high and dry.

And before that, there was Barcelona, which had a bug in the TLB cache. All AMD could do was offer a workaround to disable the cache and severely hamper performance. They couldn't fix it until the second generation Phenom. And of course once again the people who bought it were left high and dry, they couldn't exchange their early CPUs for later fixed models.
 
AMD have solved the lockup problem with FMA3 and motherboard manufacturers have started to issue BIOSes which contain the fix. As far as I'm aware there isn't a noticeable performance hit associated with this fix.
 
Other reported issues with Ryzen including people having trouble running memory at its top rated speed. There seems to be some instability in the memory controller.
 
You must log in or register to reply here.
Back
Top