The first and last of AMD’s Polaris GPUs hit the market last year, among them the RX 460 and subsequent Sapphire RX 460 Nitro 4GB, a card that underwhelmed us with unimpressive performance and an ambitious price. Just a few months later, overclocker der8auer implemented a BIOS flash to unlock additional stream processors on some RX 460 cards, bringing the count from 896 to 1024 by just flashing the card BIOS.
AMD may have inadvertently given out information today that could narrow down the release window for their upcoming Ryzen CPUs. The possible release date information was provided by a panel description for the upcoming Game Developers Conference (GDC), where AMD will host a panel detailing Zen optimization techniques for programmers. GDC 2017 takes place from February 27-March 3. This coupled with the AMD panel description from the GDC website (and our own digging while at CES) tells us that Ryzen will ship at the end of February.
In the original panel description (that has since been changed), AMD was asking session attendees to join their “Game Engineering team members for an introduction to the recently-launched AMD Ryzen CPU.” “Recently-launched” is the key phrase and indicates that the Ryzen CPU would likely already be available prior to GDC 2017, which again is February 27-March 3.
AMD’s Ryzen platform is on its march to the launch window – likely February of 2017 – and will be pushing non-stop information until its time of delivery. For today, we’re looking at the CPU and chipset architectures in greater depth, following-up on yesterday’s motherboard reveal.
First, let’s clear-up nomenclature confusion: “Zen” is still the AMD next generation CPU architecture name. “Ryzen” is the family of CPUs, comparable to Intel’s “Core” family in some loose ways. Each Ryzen CPU will exist on the Zen architecture, and each Ryzen CPU will have its own individual alphanumeric identifier (just like always).
CES 2017 allowed our team to dig deeper into the Zen architecture, its Ryzen family of CPUs, and the ensemble of AM4 motherboards in the pipes. There are currently “more than 50” SKUs of AM4 motherboards, according to the AMD team, and that’ll include the X370, B350, A320, and A/B/X300 chipsets. In this article, we’ll provide a GN-made block diagram of Ryzen’s PCIe lanes and other features, a look at ASRock and Biostar motherboards, and some brief notes on the S3.0 radiator.
Before diving in, here’s a block diagram that GamersNexus created to better represent the Ryzen / Chipset relationship:
AMD’s CES 2017 meeting room was primarily stocked with untouchable demos: Ryzen populated about half the room, Vega took a small (but critical) corner, and HDR screens took the rest. Given the challenges of demonstrating HDR in any medium other than analog (read: human eyes), we’ll skip that for now and focus on some of the Ryzen information. If Vega interests you, check out our write-up on the basics.
AMD’s suite served as a home to motherboards from MSI, Gigabyte, ASRock, and Biostar. We already spent some time with the MSI motherboards, including a look at the VRM design for each of the two configurations on display, and will today be focusing on Gigabyte’s X370, B350, and A320 motherboards. The company didn’t have any X300 mini-ITX boards at AMD’s suite, unfortunately, but did have micro-ATX displayed alongside the usual ATX form factor motherboards.
AMD’s Vega GPU architecture has received cursory details pertaining to high-bandwidth caching, an iterative step to CUs (NCUs), and a unified-but-not-unified memory configuration.
Going into this, note that we’re still not 100% briefed on Vega. We’ve worked with AMD to try and better understand the architecture, but the details aren’t fully organized for press just yet; we’re also not privy to product details at this time, which would be those more closely associated with shader counts, memory capacity, and individual SKUs. Instead, we have some high-level architecture discussion. It’s enough for a start.
Despite the general lack of official documentation on AM4, we were able to get hands-on with some early AM4 motherboards from MSI at CES 2017. This is the first time – from AMD or from others – that we’ve received any detail on the new AM4 products, and the first time they’ve been demonstrated in public. The company debuted its X370 XPOWER Titanium overclocking motherboard (For Ryzen) alongside a mid-range B350 Tomahawk board, neither yet adorned with a price. We do have a release date target, though.
During PAX Prime 2016, we posted some official documentation on lower-end AM4 chipsets that would ship to bulk buyers, for use in HP-like systems at Costco-like places. Since then, we’ve learned that the X370 platform will crown the AM4 chipset accompaniment, with B350 falling next under that, and A320 (already known, see: PAX) at the low-end. A320 would be comparable to A68, were we to draw parallels to previous generation platforms. From what MSI tells us, an X300 chipset will also exist, but is not responsible for lane assignment and I/O tasking in the same way that X370 and B350 are; instead, X300 will likely see exclusive use on SFF platforms, and will perform no substantial functions. This was also detailed in our PAX coverage.
The article title might need a few more "-zen" and "-zon" syllables.
AMD’s new Zen architecture today made its public debut under the “Ryzen” 8C/16T CPU, an IGP-less competitor to Intel’s high-end enthusiast platforms. Ryzen, a combination of “Horizon” and “Zen” (we’re told), was demonstrated as operating at approximately 3.4GHz base clock, with boosting capabilities that brought it into competition with Intel’s Broadwell-E i7-6900K.
The Ryzen CPU aims to operate at approximately 3.4GHz base clock, leveraging a form of SMT to achieve 16 logical threads on 8 physical cores. We’ve also learned that Ryzen, due out in 1Q17, will host 20MB of combined L2+L3 cache. We are presently unsure of any more specifics on the caching architecture, and are due for briefings with AMD to develop a deeper understanding of Zen and its cache.
Our full OCAT content piece is still pending publication, as we ran into some blocking issues when working with AMD’s OCAT benchmarking utility. In speaking with the AMD team, those are being worked-out behind the scenes for this pre-release software, and are still being actively documented. For now, we decided to push a quick overview of OCAT, what it does, and how the tool will theoretically make it easier for all users to perform Dx12 & Vulkan benchmarks going forward. We’ll revisit with a performance and overhead analysis once the tool works out some of its bugs.
The basics, then: AMD has only built the interface and overlay here, and uses the existing, open source Intel+Microsoft amalgam of PresentMon to perform the hooking and performance interception. We’ve already been detailing PresentMon in our benchmarking methods for a few months now, using PresentMon monitoring low-level API performance and using Python and Perl scripts built by GN for data analysis. That’s the thing, though – PresentMon isn’t necessarily easy to understand, and our model of usage revolves entirely around command line. We’re using the preset commands established by the tool’s developers, then crunching data with spreadsheets and scripts. That’s not user-friendly for a casual audience.
Just to deploy the tool, Visual Studio package requirements and a rudimentary understanding of CMD – while not hard to figure out – mean that it’s not exactly fit to offer easy benchmarking for users. And even for technical media, an out-of-box PresentMon isn’t exactly the fastest tool to work with.
There’s inherent FPS loss when using capture software, GPU-accelerated or otherwise. The best that software vendors can do is try to reduce loss as much as possible, but ideally without sacrificing too much video quality or too much compression capability.
A few months back, AMD finally axed its partnership with Raptr for the cumbersome Gaming Evolved suite. This move to greener – or ‘redder,’ perhaps – pastures immediately left AMD with a hole in its tools suite, namely a competitor to nVidia’s somewhat prolific ShadowPlay software capture tool.
Today, with the AMD ReLive update to the Crimson-brand drivers, AMD’s implemented its own solution to software capture for gameplay. The tool includes manually toggled capture, broadcast/streaming capture, and retroactive capture. This is a direct competitor to the ShadowPlay software from nVidia’s GeForce Experience suite, and performs many of the same functions with the same end objective.
We previously did this comparison with ShadowPlay versus FRAPS and AMD’s GVR, a solution that ultimately was subsumed by Gaming Evolved. It’s taken AMD a while to get back to this point, but ReLive is a fresh recording suite. In GN’s embedded video, we’ve got side-by-side capture comparisons between the two utilities, the impact on framerate when each is active, and a quick analysis of the compression’s efficacy. Much of this will also be contained below, though the quality comparison will require you view the video.