Think when Apple finally moved to Intel and th speed increase. EVEN though Apple claimed they were the as fast if no faster before the switch.
AMD had horrible performance on laptops and they are finally able to say they doubled the speed AKA they had a horrible product before.
"For its own part, AMD claims that the new Ryzen chips will offer dramatically improved performance over its own last generation of laptop chips, with up to 200 percent more CPU performance (for multicore use) and up to 128 percent better GPU performance, although AMD’s last generation of chips weren’t exactly computational powerhouses to start." https://www.theverge.com/circuitbreaker/2017/10/26/16552208/...
200% faster means “on top of the 100% of the current speed”. Think about when a toilet roll says “25% more free” and the “normal” roll is 100 sheets. I’d expect the “more” roll to have 125, or expect to have a bonus 5th roll of 100 in a 4-pack.
Yes, I think if the 8-core APU isn't happening this generation (obviously with 45+ W TDP), then it should definitely happen whenever AMD switches to the 7nm process.
I believe that they will actually go to 6-core APU, not 8.
The reason for this belief is that currently the basic building block of Zen line is the CCX, which is 4 cores. Raven ridge is 1 CCX and GPU, Ryzen chips are 2 CCX, EPYC CPUs are made of 4x ryzen, for a total of 32 cores. But, when AMD advertised their server platform, the promised that in the next generation there will be 48-core chips that will be drop-in compatible with current server boards. Because the memory channels/PCIE lanes need to remain positioned for 4 chips, they can't just put 6 chips in. This implies that they will go from 8-core Ryzen to 12-core Ryzen 2, and the smallest change to make that happen is probably a 6-core CCX. And if they drop that same CCX into their 2nd generation Zen APU, that would make it a 6-core chip.
It's the race for core counts that we've been expecting since the mid 2000s - just a lot later than anyone expected since we detoured into GPU and mobile computing.
Our software still isn't really ready for it, but I guess that's to be expected.
I wonder if we'll also move to a console-like architecture where there's only 1 pool of memory (in the case of the PS4 GDDR5) which is shared by both parts of the APU.. it would be quite nice because it allows the system to repurpose memory to whichever task is critical at that moment, you'd never have 'wasted' memory sitting around doing nothing.
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.)
The AMD drivers have gotten a complete overhaul. The open source drivers are amazing. The Nvidia drivers suck in comparison. Have you seen the post from the Sway developer that was basically "fuck you Nvidia"?
> Nvidia users are shitty consumers and I don’t even want them in my userbase.
Good Lord. I get that the EGLStream vs GBM thing is controversial, but this is childish. How are you supposed to discuss anything with someone who thinks like this.
The CUDA ecosystem is the dominant one within the GPU compute world, and it's only supported by NVIDIA hardware. And up until very recently AMD's Linux drivers were total dogshit. So there is a dominant share of NVIDIA products in this market, and it will continue to be necessary to use NVIDIA products for the foreseeable future. That's just how it is.
To be honest I've never heard of this guy nor his project before, and I'm certainly not interested in trying it after his tantrum. There will be other tiling window managers out there (and I just use a normal window manager anyway). It's NVIDIA, they have a >80% share of the discrete GPU market. Someone will fill the gap. /shrugs
Hint: Linus Torvalds' tantrums are not a positive character trait worthy of emulation. Maybe they are a necessary evil when herding a dozen teams of a dozen dozen cats each, but I'm guessing that's not the situation with this guy. It looks a lot like a fanboy ranting.
This tantrum is fairly warrented TBH. Nvidia has been hostile to the linux world for as long as they existed. That they've been in a monopoly situation means that the community had no choice but to take the pain in.
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.
I agree with you, but there arr cultural differences in perception of bluntness. Some people see it as honest. Other people see it as rude.
Knowing that, some people are going to appreciate eg If you can't set an environment variable then power user tools probably are not for you while other people are going to be needled about it.
Linux AMD open source drivers are top notch now. Even have really good foss OpenCL support. The only asterisk right now is that you only want to use these new APUs / any Vega GPU on distros running kernel 4.15 or later (which will release probably Jan of next year).
I've been playing Civ 5 on the Mesa radeon driver since it came out on Linux with great framerates. That being said, My FPS at 1080/high has gone from ~45 to over 90 in the last two years on the same 290 card.
I can replicate this experience. Enemy Territiry with radron would give you maximum 30fps in 2014 or so, forget playing with rain or on a populated server. Now I get 90fps at 1080p comfortably.
For the proprietary ones, Nvidia is still better in my experience on a Gentoo system where most everything else is from source. This Gentoo system started with Nvidia in 2009, was AMD in 2013, and this year is back on Nvidia now. AMD's old driver wasn't too bad and mostly an Nvidia-like experience with setup and stability, but after AMD's somewhat recent driver overhaul their proprietary one is a lot worse than it used to be, lacks many features or even a configuration UI, and worst it's required if you want an up-to-date X on your system. I also tried the open source AMD driver, which was its own pain (and the procedure wanted to bloat my kernel a lot) and didn't work in the end.
The open source native kernel drivers (AMDGPU) are excellent, the only minor but incredibly irritating issue is the lack of proper fan control, i.e. the GPU fan never turns off like it does on Windows. Thats why I again moved off AMD to nVidia (i like silence)
IF someone comes out with a unibody laptop with a Ryzen in it, I'm fully in. It'll easily replace my current macBook fleet.. (nb: eyes the GPD Pocket and its revisions..)
I’ve bought a Ryzen 5 for a home server, but sadly is awfully unstable. Apparently there is a bug in the Ryzen family. I’m using it with Freenas 11 (FreeBSD) and the system is having horrible random freezes with black screen. There are some threads talking about same issues, this make me lose faith in AMD, and going back to Intel.
Have you tried disabling SMT? And have you tried installing the latest microcode update? AMD has been having problems for a while, but I think they ought to have been fixed by now.
I, myself was thinking to acquire a Ryzen 5 1600 for a high performance programming desktop. I was thinking of running FreeBSD, it's sad to hear that it's glitchy.
Disabling SMT only reduces the frequency of the segfault bug occurring. AFAIK it does nothing for random whole machine freezes, for which there is a reliable workaround (other post of mine).
It is not a solved issue at all. Chips are still coming off the line with the issue, the only solid fix is getting an RMA'd processor (AMD are hand-checking these units for the issue).
The assertion of there being a "safe date range" (ostensibly, date codes >= 1730, i.e. chips manufactured during/after Week 30 2017) was made by the Phoronix Forums webmaster on the basis that he hadn't seen any user posts reporting problems with chips that had been manufactured within the last 3 weeks. Obviously it takes a while for stock to move through packaging and distribution, so this was a pretty stupid proclamation to make. Since then, chips from the "safe date range" (eg 1733) have started showing up with the segfault problem, but his mis-information persists.
The only processors that are relatively certain to not have this issue are the ones that come from filing an RMA with AMD. Full stop. And even some of those still have the issue.
It's a broad-base issue that causes general application and OS instability under load, it is not restricted to either Linux nor compilation workloads. I definitely encourage everyone to test their processor and RMA if necessary.
Well, we don't actually know if they did fix it on TR/Epyc.
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.
Merely anecdotal, but I've run heavy multi-threaded compile tests on my 1950x for days to check whether the chip was stable when overclocked, and have never seen it segfault. That was my main purpose for purchasing the CPU. I use it for that all day every day.
If I were spending millions on Epyc servers, I'd certainly test this on a reasonably large sample before committing.
Yeah, given the binning that's in play I'm not particularly worried about TR. Out of an abundance of paranoia I would recommend a 24h run of kill-ryzen.sh on literally any Ryzen/TR processor (including RMA replacements) but TR is not likely to be a problem. For that matter, the chips that are taking 24h+ to segfault are not likely to be a problem either. It's the ones that are segfaulting in a matter of seconds or minutes that are going to be problematic for normal users.
However, that's my thoughts as to why we're not seeing it on Threadripper despite it being on the same stepping. If it were a simple microcode fix (even if you needed to disable some codepath and cut a few percent off) then there is no reason not to pass that down to consumer Ryzen. So far, however, a microcode fix has not been forthcoming. So it's either TR is better binned and thus less subject to the fault, or that something about TR's NUMA layout is breaking one of the necessary conditions for the cache fault to occur.
I do think AMD stepped up their QA after the fault was discovered. I've actually heard of post-week-30 retail samples passing kill-ryzen runs, whereas essentially 100% of the pre-week-25 chips display the fault. However, there are definitely post-week-30 chips that do still display the fault.
I assume what's going on there is AMD is doing a quick run of kill-ryzen to weed out the shittiest chips, the ones that die in seconds/minutes. But since there isn't a way to deterministically reproduce this fault, and AMD can't realistically spend 24h testing every single chip for one fault, some of the only-somewhat-shitty chips are still leaking through their QA testing.
I would take a random week 33 chip over a random week 08 chip for sure, the quality is definitely up, but week 30+ is no guarantee that your chip won't segfault either.
If your system is totally new, try checking your RAM with memtest too.
My Threadripper build had similar issues in Linux and Windows. Ended up being my PSU. I tried to save $30 buying a refurb one from Corsair. My system would lock up occasionally at totally stock settings and even shutdown on its own. Works perfectly now after I swapped it out.
FWIW, I'm really happy with the Threadripper/X399. Most of the early Ryzen bugs are worked out. It's a great value for the performance. Compiling large C or C++ code bases is insanely fast.
Still, I'd be wary of buying AMD's first gen mobile offering. When you buy a laptop you're buying a whole system and battery life, no glitches after sleep/wake, heat, noise, etc. trump raw performance. Intel has way more experience there. This Radeon iGPU also sits in a weird market segment. People who don't game/render/3D model on the go do just fine with the weak Intel iGPU. People who really care about that stuff can get a big laptop with faster dGPU or just do 3D on their desktop. So I guess their target is people who casually game but want a thin-ish laptop?
NB: I don't doubt AMD's ability to make a decent mobile platform. Just Intel has shipped hundreds of millions more units, so they've seen every "system crashes after sleep when re-pairing with $OBSCURE_BLUETOOTH_DEVICE" issue on earth. On a desktop you can always swap hardware, but on a laptop you're stuck with what you get.
> On a desktop you can always swap hardware, but on a laptop you're stuck with what you get.
Raven Ridge is the same stepping as Ryzen, i.e. potentially subject to the segfault bug. I'm really curious whether it will manifest there too or not.
It's a pretty generic errata that manifests under load. Compiling happens to be one way that flushes it out pretty reliably (as with many errata), and nerds do a lot of compiling in Linux, but it can and does manifest as general OS and application crashiness even in other operating systems (including in Windows). It's a ticking time-bomb, sooner or later some OS or application update could hit the trigger conditions more regularly.
There's nothing quite like being "the brand that randomly crashes all the time" to build a brand image with your customers. And I'm sure OEMs are going to love handling RMAs for AMD's defective processors.
Laptop RMAs are way more expensive since they have to swap the entire board w/CPU or reflow solder on a new chip. Can't imagine any OEM will willingly take that hit. Since these issues are well known, I'd bet AMD has to fix them; OEMs will mandate it as part of QA. Either that or they'll force AMD to eat the costs like Apple did with NVidia.
This is a known issue that only affects early revisions of Ryzen CPUs under specific workloads, so it's unlikely to appear in new ones like the mobile Ryzen. If you're affected, AMD will RMA your chip for free.
And AMD isn't the only manufacturer to have such issues. Intel had a bug in Skylake where it would crash under heavy load with Hyperthreading enabled. Modern CPUs are complicated beasts.
How do you RMA the CPU in a laptop though, I would expect it to be soldered in?
I guess through the manufacturer who gets to rework the main board ... gah how annoying that must be. I can easily imagine such a process taking weeks.
Unfortunately anyone who takes their security or privacy seriously will be totally unable to use this. Every AMD chip contains a likely backdoored system called AMD Secure Processor (formerly “Platform Security Processor” or “PSP”) [1].
This separate processor contains closed source, proprietary binaries that have complete and unrestricted access to the host. Despite a large petition for AMD to opensource this, they refused in the end. [2][3]
Anyone running AMD chipsets have a completely separate and unaccessible operating system running on their computer that they can not control nor know exactly what it's doing. [4]
Intel has the same sort of system with it's Intel Management Engine (known as Intel ME) that even the NSA didn't want to have running on their own computers. [5]
Looking at [4] tells me that no modern, relevant CPU supports what libreboot needs/requires, so while not a good point it doesn't help deciding between AMD or Intel - and those are, for better or worse, the only relevant CPUs for laptops/desktops.
> Unfortunately anyone who takes their security or privacy seriously will be totally unable to use this. Every AMD chip contains a likely backdoored system called AMD Secure Processor
This is fear mongering to the extreme. Intel has the exact same type of system embedded in their processors called Intel Management Engine. You can't escape this problem by buying Intel.
I notice you provided a lot of sources, but none for the claim "a likely backdoored system". Your post reads like something a bad Intel astroturfing shill would say.
You don't need soldering skills (at least for the device I use), but I agree it's not trivial. However, a nontrivial fix is still a significant improvement over a nonexistent one.
Does this exist on Epyc platforms that don't use a traditional chipset?
This is bad, but seems like more of an incremental issue than anything. Can you audit every line of source in your system? No closed source drivers or firmware on any devices? No devices on your network with vendor controlled firmware? You log all network I/O through a passive tap? For the average user targeted by a state actor this makes little difference.
I've always had a soft spot for AMD, the rebel, the chief rival to the behemoth Intel. I'm glad for this move, and I hope they create meaningful competition.
This should make life easier for Linux users who want something better than integrated Intel GPU. No more Optimus horrors and lack of proper PRIME support.
You need a new kernel to support a GPU? What ass-backwards garbage is this? With Windows, it's install a new driver; not update the core of the OS and possibly introduce horrible bugs.
Yep, utterly backwards. That kind of thing should be purely in driver space where it belongs, hooked on a driver model and not a kernel upstream model.
It's funny that Microsoft learned this problem and fixed it back in 2007-ish. Well, in another 30 years Linux will catch up. Maybe.
MS didn't fix it. They simply froze their abstraction and everyone expects it to be the same. Linux supports kernel modularity for a long time already. The only difference - they don't guarantee interfaces to be set in stone. So clearly they aren't interested in "catching up", since they do it on purpose.
I don't necessary agree that it works for their goals (preventing messed up un-upstreamable kernel modules), but they do it for a reason.
Linux can't lose the GPU without taking the entire system or the program it's operating down. Windows can have the entire subsystem crash and come right back up almost instantly without loss of screen data, including active game windows.
Microsoft most certainly fixed their graphics problems that were rampant from NT4 through Vista.
hint: it has something to do with the fact that Windows machines have a reputation for BSoDing regularly, whereas Linux systems have no such reputation.
Hah. I've been through kernel panic hell more times than years in my age, and I'm OLD. You must be real new to the Linux world if you think it has a spotless record.
In fact, it's still possible to hardlock the kernel all these years after I reported how. Lemme show you how poorly the Kernel handles an encrypted RAMDisk with a couple configured parameters.
Well, Windows notably switched to a new graphics driver model in Vista that puts parts of graphics drivers in userland, in order to allow them to crash without taking down the system. But I think that's comparable to what Linux has always been doing with Mesa vs. DRM; not sure what the details look like though.
"So why do you pretend NOT to know at all that the kernel handles/provides drivers?"
You're failing at reading and understanding any of my words, which means you're likely looking to start a problem. Okay, I'll play along.
I know that the Kernel handles and provides drivers - what you're failing to understand is that I think it's HORRIBLE (and I can prove it hundreds of different ways on any Linux distro excepting maybe SELinux and its flavors.)
Wake me up when the entire Linux graphics subsystem can crash without taking the entire computer, or one single app, along with it. Windows can do this. Linux can not. Linux is therefore doing things poorly.
Even BSD handles this better. Every other OS excepting Linux has bothered to come into the modern age of graphics subsystems around 2007/2008. Linux is still behind and will remain so for the foreseeable future.
For Linux it's IME not BSODs, but deficiencies in desktop usage situations. A CPU and I/O scheduler that causes sound stuttering (now better than five years ago), or my favorite... CDs with read errors can hang much of the user interface forever and effectively require a restart. Not even mechanically force-ejecting the CD helps. It is AFAIK not due to programming errors in the UI - processes become unkillably stuck. Fortunately it isn't very relevant anymore. It may even have been fixed and I haven't noticed.
Network drives going away will still reliably hang explorer processes. It’s 2017, there’s no reason to be doing network access on the UI thread anymore.
I've been using Ubuntu desktop for over ten years. My experience is that every now and then it just stops and needs a hard reset. Not as polite as a BSOD.
If anything Linux Desktops are way less stable than Windows Desktop. Try crashing a graphics driver on Linux and see what happens and compare that to Windows (it restarts without interrupting operation). Most of the Linux schedulers are awful for interactive use as well. I'm forced to use Debian and Scientific Linux installations at work, they are so much worse at basically anything I've experienced both on Windows and macOS it is not even funny.
I experience somewhat frequent GPU crashes when playing Diablo3 under Wine with the integrated i3-4150 GPU, but the graphics stack recovers by itself in about a minute. I can then continue from where I left off, sans the application that crashed with it.
Under Windows the recovery is instant, there is an audible bell and a popup window in the taskbar saying something along the lines of: "The graphics driver has crashed and has been restarted". In any case by now I'm pretty sick of Linux fanboys making fun of people using other operating systems. Using Linux as a Desktop OS, especially if your are not given a chance to modify the installation is an exercise in self-flagellation.
In addition to the other comments. Ubuntu's LTS, if you install hardware enablement stack, will automatically install new kernels once Ubuntu releases them for the LTS.
The desktop version does this automatically... if you install the LTS from a XX.XX.02 release: Ubuntu 16.04.2 does this. Ubuntu 16.04.1 does not-you have to manually enable it.
Drivers tend to get fixed far faster than Kernels do. I'm speaking from personal experience in my reporting multiple issues with the Linux Kernel. In fact, as I look, the eight I reported years ago are still there, which means the inherent memory vulnerability is still there and Linus (improperly) chose to use ASLR to try to mitigate it instead of fixing it properly in the first place.
And you want to make Microsoft look the worse party. That's hilarious.
Desktop Ryzen still suffers with thermal/power efficiency issues compared to desktop Intel cores, so I wonder if they've managed to address that issue for these mobile cores. If not, I wonder how customers will feel about paying a battery life tax for better performance...
Incidentally, AMD GPUs have been at a disadvantage compared to NVIDIA's in the power management area for a while, as well. Which is unfortunate because they're very good cores with (arguably) a better feature set for compute/rasterization than NVIDIA's. Intel seems to have the market for low-power GPUs on PC sewn up as well. If AMD manages to make improvements here they could put out a very compelling product, if only because you wouldn't need GPU-switching in your laptop (with all the hassle that entails) and it'd be easier to substitute a laptop for your desktop when you do compute-heavy work.
For example, https://www.anandtech.com/show/11658/the-amd-ryzen-3-1300x-r... shows worse idle power draw and worse load power draw for Ryzen. In desktop cases this gap doesn't matter as long as you have a good heatsink+fan but it will map to worse battery life and worse noise/thermals in a laptop. (An extra thirty watts in total system draw under load can add up on your utility bill, though.)
Power draw on AMD's GPUs is not great either, unfortunately: https://www.anandtech.com/show/11717/the-amd-radeon-rx-vega-...
And past GPUs they've released also had issues with drawing more power over the PCIe slot than it was rated for (and exceeding their TDP in general, I believe).
5% is a lot these days, and that Intel CPU will beat Ryzen clock-for-clock as well. Laptop manufacturers are fighting over every percentage point of gains these days, not trying to move backwards. People want to see all day battery life with reasonably good performance.
I like AMD and want more competition for Intel. If you have a use that scales across many cores, AMD is a great value for workstations. Their new server lineup is pretty compelling too. But if they want to win in mobile they need to be better on power and thermals even for normal users who won't use the iGPU's capabilities heavily.
The point is, this comparison is between a 4 core CPU (Ryzen) vs 2/4 cores CPUs (i3 and i5). Vs i5 the difference is less than 1%, vs i3 the difference is 5%.
Comparing power draw on full load on 2 different CPUs is not apple to apple comparison unless they are doing same thing. In benchmarks you have linked Ryzen CPUs are also more powerful.
For example - if I am compiling Linux Kernel and Ryzen takes more power but compilation is faster then my laptop can hit lower power state faster after it is done compiling. And 1500x for example is way faster than all CPUs in linked benchmark.
I do agree about Idle power draw though, but it seems very small difference.
I think in the end, we will have to wait for official benchmarks from reviewers before concluding anything. We can't draw our conclusions from AMD's marketing material.
Finally laptops gets freed from 2 anemic cores. Intel will now 'suddenly be in a position' to rush reasonably priced 4 cores to the laptop market.
AMD needs to be competitive for the health of the industry and consumers. There is little doubt now Intel was holding the market back.
We have seen similar stagnation on desktops with any slight step magnified by the tech press desperate for content. And fortunately AMD have an efficient architecture with Ryzen.
Dear AMD, please turn on SR-IOV for your GPUs on these laptops. I want to be able to use it in multiple VMs. This is a huge selling point for some people, I will go with Intel because they have GVT-g enabled on all their chips.
I have a Lenovo Ideapad y510p [newegg] with a i7 4700MQ [ark]. Cost me $999 when I bought it too (got $50 back after price match with Amazon bringing cost down to $950). Anyways, I play with VirtualBox a lot as well and would love to know more about compatibility with Linux. I am on Fedora 26 for my base os (that I am typing this on) now and nVidia proprietary drivers have been nothing but trouble so I just stick with whatever the distro comes with.
I would like to know about the progress with SR_IOV as well. I've never had an AMD processor but would definitely welcome some competition. AMD, if you're reading having graphics drivers "mainline" in the Linux kernel would be a huge plus. Thank you!
144 comments
[ 3.3 ms ] story [ 155 ms ] threadIt would be nice to have an octa-core in a laptop.
Also would be really nice to have Vega as well — current Radeons aren't very good compared to 10-series nVidia chips.
Think when Apple finally moved to Intel and th speed increase. EVEN though Apple claimed they were the as fast if no faster before the switch.
AMD had horrible performance on laptops and they are finally able to say they doubled the speed AKA they had a horrible product before.
"For its own part, AMD claims that the new Ryzen chips will offer dramatically improved performance over its own last generation of laptop chips, with up to 200 percent more CPU performance (for multicore use) and up to 128 percent better GPU performance, although AMD’s last generation of chips weren’t exactly computational powerhouses to start." https://www.theverge.com/circuitbreaker/2017/10/26/16552208/...
2000 mhz * 2 is 4000 mhz
Tripple would be 300%
The reason for this belief is that currently the basic building block of Zen line is the CCX, which is 4 cores. Raven ridge is 1 CCX and GPU, Ryzen chips are 2 CCX, EPYC CPUs are made of 4x ryzen, for a total of 32 cores. But, when AMD advertised their server platform, the promised that in the next generation there will be 48-core chips that will be drop-in compatible with current server boards. Because the memory channels/PCIE lanes need to remain positioned for 4 chips, they can't just put 6 chips in. This implies that they will go from 8-core Ryzen to 12-core Ryzen 2, and the smallest change to make that happen is probably a 6-core CCX. And if they drop that same CCX into their 2nd generation Zen APU, that would make it a 6-core chip.
Our software still isn't really ready for it, but I guess that's to be expected.
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.)
But for some reason I dont think Apple cares anymore. They will continue to have HDD as standard and crappy Intel iGPU.
Intel has announced that Thunderbolt 3 will become royalty-free in 2018[1], but it's gonna be a long while before ever getting to market.
[1] http://www.techradar.com/news/intel-has-a-grand-plan-to-brin...
[0]: https://heise.cloudimg.io/bound/2300x1400/tjpeg.q90.webp-los...
See https://www.amd.com/en/products/apu/amd-ryzen-7-2700u
But now that I might be able to get a 3 pound ultrabook with decent graphics, I'm willing to put up with a lot more inconvenience .
Good Lord. I get that the EGLStream vs GBM thing is controversial, but this is childish. How are you supposed to discuss anything with someone who thinks like this.
To be honest I've never heard of this guy nor his project before, and I'm certainly not interested in trying it after his tantrum. There will be other tiling window managers out there (and I just use a normal window manager anyway). It's NVIDIA, they have a >80% share of the discrete GPU market. Someone will fill the gap. /shrugs
Hint: Linus Torvalds' tantrums are not a positive character trait worthy of emulation. Maybe they are a necessary evil when herding a dozen teams of a dozen dozen cats each, but I'm guessing that's not the situation with this guy. It looks a lot like a fanboy ranting.
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.
Really? Weren't they the only ones who released a driver for like a decade?
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.
I had this exchange with him: https://news.ycombinator.com/item?id=15511570
Knowing that, some people are going to appreciate eg If you can't set an environment variable then power user tools probably are not for you while other people are going to be needled about it.
https://wiki.archlinux.org/index.php/fan_speed_control
If so, then you should be able to control them manually.
Also, they have pretty good API support: https://mesamatrix.net/
Only Intel is slightly better on that, but their performance is abysmal.
https://www.phoronix.com/scan.php?page=article&item=rx-vega-...
I, myself was thinking to acquire a Ryzen 5 1600 for a high performance programming desktop. I was thinking of running FreeBSD, it's sad to hear that it's glitchy.
The assertion of there being a "safe date range" (ostensibly, date codes >= 1730, i.e. chips manufactured during/after Week 30 2017) was made by the Phoronix Forums webmaster on the basis that he hadn't seen any user posts reporting problems with chips that had been manufactured within the last 3 weeks. Obviously it takes a while for stock to move through packaging and distribution, so this was a pretty stupid proclamation to make. Since then, chips from the "safe date range" (eg 1733) have started showing up with the segfault problem, but his mis-information persists.
https://community.amd.com/thread/215773?start=1770&tstart=0
The only processors that are relatively certain to not have this issue are the ones that come from filing an RMA with AMD. Full stop. And even some of those still have the issue.
It's a broad-base issue that causes general application and OS instability under load, it is not restricted to either Linux nor compilation workloads. I definitely encourage everyone to test their processor and RMA if necessary.
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.
If I were spending millions on Epyc servers, I'd certainly test this on a reasonably large sample before committing.
However, that's my thoughts as to why we're not seeing it on Threadripper despite it being on the same stepping. If it were a simple microcode fix (even if you needed to disable some codepath and cut a few percent off) then there is no reason not to pass that down to consumer Ryzen. So far, however, a microcode fix has not been forthcoming. So it's either TR is better binned and thus less subject to the fault, or that something about TR's NUMA layout is breaking one of the necessary conditions for the cache fault to occur.
I do think AMD stepped up their QA after the fault was discovered. I've actually heard of post-week-30 retail samples passing kill-ryzen runs, whereas essentially 100% of the pre-week-25 chips display the fault. However, there are definitely post-week-30 chips that do still display the fault.
I assume what's going on there is AMD is doing a quick run of kill-ryzen to weed out the shittiest chips, the ones that die in seconds/minutes. But since there isn't a way to deterministically reproduce this fault, and AMD can't realistically spend 24h testing every single chip for one fault, some of the only-somewhat-shitty chips are still leaking through their QA testing.
I would take a random week 33 chip over a random week 08 chip for sure, the quality is definitely up, but week 30+ is no guarantee that your chip won't segfault either.
If your system is totally new, try checking your RAM with memtest too.
My Threadripper build had similar issues in Linux and Windows. Ended up being my PSU. I tried to save $30 buying a refurb one from Corsair. My system would lock up occasionally at totally stock settings and even shutdown on its own. Works perfectly now after I swapped it out.
FWIW, I'm really happy with the Threadripper/X399. Most of the early Ryzen bugs are worked out. It's a great value for the performance. Compiling large C or C++ code bases is insanely fast.
Still, I'd be wary of buying AMD's first gen mobile offering. When you buy a laptop you're buying a whole system and battery life, no glitches after sleep/wake, heat, noise, etc. trump raw performance. Intel has way more experience there. This Radeon iGPU also sits in a weird market segment. People who don't game/render/3D model on the go do just fine with the weak Intel iGPU. People who really care about that stuff can get a big laptop with faster dGPU or just do 3D on their desktop. So I guess their target is people who casually game but want a thin-ish laptop?
NB: I don't doubt AMD's ability to make a decent mobile platform. Just Intel has shipped hundreds of millions more units, so they've seen every "system crashes after sleep when re-pairing with $OBSCURE_BLUETOOTH_DEVICE" issue on earth. On a desktop you can always swap hardware, but on a laptop you're stuck with what you get.
Raven Ridge is the same stepping as Ryzen, i.e. potentially subject to the segfault bug. I'm really curious whether it will manifest there too or not.
It's a pretty generic errata that manifests under load. Compiling happens to be one way that flushes it out pretty reliably (as with many errata), and nerds do a lot of compiling in Linux, but it can and does manifest as general OS and application crashiness even in other operating systems (including in Windows). It's a ticking time-bomb, sooner or later some OS or application update could hit the trigger conditions more regularly.
There's nothing quite like being "the brand that randomly crashes all the time" to build a brand image with your customers. And I'm sure OEMs are going to love handling RMAs for AMD's defective processors.
https://news.ycombinator.com/item?id=14936468
http://www.phoronix.com/scan.php?page=article&item=ryzen-seg...
And AMD isn't the only manufacturer to have such issues. Intel had a bug in Skylake where it would crash under heavy load with Hyperthreading enabled. Modern CPUs are complicated beasts.
I guess through the manufacturer who gets to rework the main board ... gah how annoying that must be. I can easily imagine such a process taking weeks.
I hope you're right. :)
This separate processor contains closed source, proprietary binaries that have complete and unrestricted access to the host. Despite a large petition for AMD to opensource this, they refused in the end. [2][3]
Anyone running AMD chipsets have a completely separate and unaccessible operating system running on their computer that they can not control nor know exactly what it's doing. [4]
Intel has the same sort of system with it's Intel Management Engine (known as Intel ME) that even the NSA didn't want to have running on their own computers. [5]
[1] http://www.amd.com/en-us/innovations/software-technologies/s...
[2] https://www.reddit.com/r/privacy/comments/5z4phx/petition_fo...
[3] https://www.reddit.com/r/Amd/comments/6msujx/what_happened_t...
[4] https://libreboot.org/faq.html#amd
[5] https://www.theregister.co.uk/2017/08/29/intel_management_en...
This is fear mongering to the extreme. Intel has the exact same type of system embedded in their processors called Intel Management Engine. You can't escape this problem by buying Intel.
I notice you provided a lot of sources, but none for the claim "a likely backdoored system". Your post reads like something a bad Intel astroturfing shill would say.
This is bad, but seems like more of an incremental issue than anything. Can you audit every line of source in your system? No closed source drivers or firmware on any devices? No devices on your network with vendor controlled firmware? You log all network I/O through a passive tap? For the average user targeted by a state actor this makes little difference.
Users will have to wait for 4.15 - until mid-late January.
It's funny that Microsoft learned this problem and fixed it back in 2007-ish. Well, in another 30 years Linux will catch up. Maybe.
I don't necessary agree that it works for their goals (preventing messed up un-upstreamable kernel modules), but they do it for a reason.
Linux can't lose the GPU without taking the entire system or the program it's operating down. Windows can have the entire subsystem crash and come right back up almost instantly without loss of screen data, including active game windows.
Microsoft most certainly fixed their graphics problems that were rampant from NT4 through Vista.
Hah. I've been through kernel panic hell more times than years in my age, and I'm OLD. You must be real new to the Linux world if you think it has a spotless record.
In fact, it's still possible to hardlock the kernel all these years after I reported how. Lemme show you how poorly the Kernel handles an encrypted RAMDisk with a couple configured parameters.
So why do you pretend NOT to know at all that the kernel handles/provides drivers? If you're so experienced you should be well aware of that.
You're failing at reading and understanding any of my words, which means you're likely looking to start a problem. Okay, I'll play along.
I know that the Kernel handles and provides drivers - what you're failing to understand is that I think it's HORRIBLE (and I can prove it hundreds of different ways on any Linux distro excepting maybe SELinux and its flavors.)
Wake me up when the entire Linux graphics subsystem can crash without taking the entire computer, or one single app, along with it. Windows can do this. Linux can not. Linux is therefore doing things poorly.
Even BSD handles this better. Every other OS excepting Linux has bothered to come into the modern age of graphics subsystems around 2007/2008. Linux is still behind and will remain so for the foreseeable future.
https://wiki.ubuntu.com/Kernel/LTSEnablementStack
The desktop version does this automatically... if you install the LTS from a XX.XX.02 release: Ubuntu 16.04.2 does this. Ubuntu 16.04.1 does not-you have to manually enable it.
Windows drivers are typically the source of Windows' horrible bugs. It's no different.
And you want to make Microsoft look the worse party. That's hilarious.
In windows world; but in my experience that's 6-12 months for driver, to 12-24 for kernel.
In linux world, kernels (and drivers) get fixed much much faster, in the order of a couple of months.
Incidentally, AMD GPUs have been at a disadvantage compared to NVIDIA's in the power management area for a while, as well. Which is unfortunate because they're very good cores with (arguably) a better feature set for compute/rasterization than NVIDIA's. Intel seems to have the market for low-power GPUs on PC sewn up as well. If AMD manages to make improvements here they could put out a very compelling product, if only because you wouldn't need GPU-switching in your laptop (with all the hassle that entails) and it'd be easier to substitute a laptop for your desktop when you do compute-heavy work.
For example, https://www.anandtech.com/show/11658/the-amd-ryzen-3-1300x-r... shows worse idle power draw and worse load power draw for Ryzen. In desktop cases this gap doesn't matter as long as you have a good heatsink+fan but it will map to worse battery life and worse noise/thermals in a laptop. (An extra thirty watts in total system draw under load can add up on your utility bill, though.)
Power draw on AMD's GPUs is not great either, unfortunately: https://www.anandtech.com/show/11717/the-amd-radeon-rx-vega-... And past GPUs they've released also had issues with drawing more power over the PCIe slot than it was rated for (and exceeding their TDP in general, I believe).
That is a pretty small (<5%) gap.
I like AMD and want more competition for Intel. If you have a use that scales across many cores, AMD is a great value for workstations. Their new server lineup is pretty compelling too. But if they want to win in mobile they need to be better on power and thermals even for normal users who won't use the iGPU's capabilities heavily.
For example - if I am compiling Linux Kernel and Ryzen takes more power but compilation is faster then my laptop can hit lower power state faster after it is done compiling. And 1500x for example is way faster than all CPUs in linked benchmark.
I do agree about Idle power draw though, but it seems very small difference.
I think in the end, we will have to wait for official benchmarks from reviewers before concluding anything. We can't draw our conclusions from AMD's marketing material.
Correct. And here's why: https://www.realworldtech.com/tile-based-rasterization-nvidi...
AMD needs to be competitive for the health of the industry and consumers. There is little doubt now Intel was holding the market back.
We have seen similar stagnation on desktops with any slight step magnified by the tech press desperate for content. And fortunately AMD have an efficient architecture with Ryzen.
I would like to know about the progress with SR_IOV as well. I've never had an AMD processor but would definitely welcome some competition. AMD, if you're reading having graphics drivers "mainline" in the Linux kernel would be a huge plus. Thank you!
[newegg] https://www.newegg.com/Product/Product.aspx?Item=N82E1683431... https://archive.fo/iFkUO
[ark] https://ark.intel.com/products/75117/Intel-Core-i7-4700MQ-Pr... https://archive.fo/5SpgX
Envy x360 seems the most promising, but doesn't seem to come with the Ryzen 7 2700U. So probably not.
Ideapad 720S has memory limitations (no dual channel support) and is straight out.
Swift 3 seems to be the closest to what I want - but .. limited to 8GB :-/
Given that I'm currently, right now, in the market for a laptop, I guess I've got to skip AMD for now.