AMD takes on Intel with new Ryzen processors for laptops

It detoured into a company having no need to improve its products too much because they were already the best. If the technology is somewhat stagnating, it is best not to release all the improvements at once. After core counts have increased, what else will still make people buy new CPUs? Maybe I lack some imagination here - and so do companies making phone CPUs, which can't think of anything better than upping the core count.

Also, high core count CPUs are slightly more similar to GPUs, and Intel seems to be trying to keep the GPU threat at bay. There is no reason to believe that Intel couldn't design a competitive high end GPU, but that is not where its entrenched advantage is. (This part is not my own analysis, I read it somewhere else and consider it highly plausible.)

Sway is a WM, and wlroots is a new library that should help in creating Wayland WMs (similar to wlc). SirCmpwn has to maintain all of that, and it turns out it's a fairly big task. Realistically, his WM will run on hardware running Intel for the most part, with AMD or Nvidia way behind. Optimizing for Intel is fairly simple, and it turns out it gives AMD support for free, since they use the agreed-upon APIs. His choice makes sense.

The thing is, people are going to always ask why that choice have been made. And I can understand this being super-frustrating, hence the post being so harsh on nvidia. But really, nvidia deserves it. Wayland wasn't designed in a vacuum, and nvidia took the wait and see approach. Once every bit were put in place, Nvidia came up with the EGLStream proposal. Not during discussion. After everything was said and done. Adding a codepath for EGLStream is really non-trivial, and I hope nobody does it because it really adds additional complexity.

Really, that AMD is getting more competitive is going to help the GPU world a lot. Nvidia has always been a bad citizen there, and oh boy if AMD ever gets in a position where they can compete on compute, that'd be great.

Well it's not. He's the one who has to do the work, and if I were in his position, I wouldn't do it either. Like if you ordered a coca cola machine compatible syrup pack, and instead received a pepsi co. one, and the manufacturer tells the court that they fulfilled your order even though you are left to accommodate something other than what they claimed to provide.

What NVIDIA has done is claim to support something, while in reality supporting something entirely different and ancillary which everyone else has to do work to accommodate. SirCmpwn isn't "fanboy ranting", he is talking about how ridiculous it is that NVIDIA has pushed the onus for supporting something which is effectively their own proprietary API on the rest of the ecosystem, for apparently no technical reason, and with either no consideration, or malice of intent.

Epyc is on a newer stepping (that has not been released to the consumer market yet), but the issue was only acknowledged a couple months ago. The B2 stepping may already have been taped out at that point. We don't really know because you pretty much can't get ahold of Epyc systems at the moment (at the moment, the only way is by ordering prebuilt servers from SuperMicro). There hasn't been the degree of testing that you have on Ryzen. But, if the B2 stepping does contain a fix, that would be the reason that Epyc is immune.

Threadripper is on the same stepping, but it's cherrypicked silicon (AMD claims they're the top 5% of silicon off the line). There is a wide range of severity reported with Ryzen processors, some people segfault in seconds, others it takes 24h+ of testing before it manifests. That strongly suggests that it's a litho problem, and the fact that Threadripper is on cherrypicked silicon may insulate it somewhat from this issue. But in general I don't see any guarantee there either. There isn't anywhere near as much testing as there is on Ryzen here either (although certainly more than Epyc).

From what I've read the finger points pretty strongly at a cache problem (likely the uop cache) and it's also possible that TR/Epyc's NUMA configuration somehow avoids the trigger conditions for this bug. I don't think this case is particularly likely but it's one possible explanation.

Frankly though I don't understand why AMD hasn't released the B2 stepping to the consumer market. They are using it for Epyc but they are still producing Ryzen and TR on the original B1 stepping and appear to be releasing Raven Ridge on the B1 stepping as well. I don't know whether the B2 stepping contains a fix for this issue, but I'm sure it has some general fixes that would be good to have.