- Dec 5, 2015
"Lazarus".Is it something you've heard or just saying that for posterity?
I think we'll know much more about the IOV by the time the server SKUs (Naples and Snowy Owl) hit the market. There is no way to launch the server platform without having the virtualization features fully functional and documented.Sorry The Stilt for hijacking a bit your interesing Thread, but for anyone that is into Passthrough as I do, I got the lspci output from Patrick from ServeTheHome from a Ryzen in an ASUS PRIME B350-PLUS. The PCI topology looks like this. I actually find it rather clean and flexible.
I hear from this video that there seems to be poor isolation, and everything gets in the same IOMMU Group, or something like that (I don't see that they show log info or anything related to see how it actually looks). However, that means that they DID enable the IOMMU for the Linux Kernel (Else you won't get the IOMMU Groups constructs) and the Kernel didn't panicked when doing so. Since its an isolation issue, what seems to be broken is PCIe ACS, AMD-Vi/IOMMU itself works. However, with no further info is impossible to know what is broken.
For reference, Skylake and Kaby Lake Chipsets also initially had ugly IOMMU Groups because the Chipset has a PCIe ACS related Errata, the ACS is found at an slight offset compared to the what the specifications says that it should be found at. Thus, for proper functionality, they require that you're using a Linux Kernel that had the fix to the quirk included so you get proper IOMMU Grouping. Since most people focuses on Ubuntu, chances are that if there was some last minute work or fixes for Ryzen that got include in the latest Linux Kernel, they are missing them. A bleeding edge distribution like Arch Linux, or a self compiled Linux Kernel from git, could be more interesing for Ryzen.
A thing which extremely surprises me is Ryzen performance-per-Watt, is like AMD not only got competitive with Intel, but can actually beat it if you focus in that metric. I think that Ryzen weakness is the low Frequency ceiling, 4-4.2 GHz is not enough to put a good show against high Frequency Kaby Lakes in classical desktop workloads and gaming, but for Linux Server workloads it is AMAZINGLY IMPRESSIVE. Also, the binning that 1800X may require puts it extremely close to the "factory overclock" definition, taking away the performance-per-Watt and the fun of overclocking. Ryzen could put an excellent show if it stays at the 3.3 GHz Critical 1 Point, which is why the 1700 looks soo good.
On Server workloads where performance-per-Watt is more important, is probable that Ryzen may be dramatically better. I think that ultimately, that is what will help AMD the most, especially from a profitability point of view, since AMD marketshare on Servers (Which got higher profit magins) was pretty much nonexistant since Sandy Bridge, and Ryzen could help get in with force. Desktop workloads doesn't showcase what it can truly do, it just shows its weakness. It could have made more sense if they focused on Server-first, as the original AMD K8 where Opterons came like 6 months before Athlons 64, but all the present issues shows instead that it would have been a product too inmature for that...
I believe that Ryzen is "Bulldozer done right". I had the same expectatives from Ryzen that I had from Bulldozer (Reducing the ST gap with Intel to the "good enough" point, but dramatically better MT performance at similar price points), just that this time AMD delivered.
BTW, what are the chances that we may see a midterm Ryzen refresh? I remember the Phenom II C2 vs C3 and Piledriver FX 8320E (Which was a more optimized Stepping. I recall a Thread from The Stilt talking about it some years ago). If Ryzen 4C/6C parts gets an extra 300-500 MHz headroom, it will seriously threat mainstream Kaby Lakes in ST. But at that point, it may have to face Coffee Lake instead...
Starting from Carrizo AMD has put surprisingly ample amount of resources into Linux.
If I would get to decide what AMD would do with Zeppelin:
- Iron out all of the existing shenanigans (obviously), where possible.
- Rewrite the Turbo & XFR algorithms in the SMU: Turbo & XFR are maintained during "OC-Mode" operation, Turbo & XFR CPUFID/CPUDFSId/CPUVID are made user configurable
- Start porting Zeppelin on 16nm FF+. Porting the design and all of the re-tooling it involves will be extremely costly, however it would be definitely worth it if it allows hitting even 300MHz higher Fmax on average, which it most likely would. Release as a refresh e.g. 1750, 1750X, 1850X.