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).
Optane is Intel’s latest memory technology. The long-term goal for Optane is for it to be used as a supplemental system memory, caching storage, and primary storage inside PCs. Intel claims that Optane is faster than Flash NAND, only slightly slower than DRAM, has higher endurance than NAND, and, due to its density, will be about half the cost of DRAM. The catch with all of these claims is that Intel has yet to release any concrete data on the product.
What we do know is that Lenovo announced that they will be using a 16GB M.2 Optane drive for caching in a couple of their new laptops during Q1 2017. Intel also announced that another 32GB caching drive should be available later in the year, something we’ve been looking into following CES 2017. This article will look into what Intel Optane actually is, how we think it works, and whether it's actually a viable device for the enthusiast market.
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.
We recently prolonged the life of GN Andrew’s Lenovo laptop, a task accomplished by tearing the thing down and cleaning out the dust, then re-applying thermal compound. This brought temperatures down well below 80C on the silicon components, where the unit was previously reaching 100C (or TjMax values and thereby throttling). The laptop has lived to work many more long render sessions since that time, and has been in good shape since.
That’s gotten us a bit of a reputation, it seems, as we just recently spent a few hours fixing a Dell Studio XPS 1640 and its noise issues.
The 1640 had a few problems at its core: The first, loud noise during idle (desktop); the second, slowing boot times with age; and the third, less-than-snappy responsiveness upon launching applications.
Subscribers of our YouTube channel will know that we’ve been hastily assembling a gaming HTPC for the last few days, dedicated as a gift for Andie (my sister, and also occasional tester for the site). We started on the 21st, with limited time to order any missing parts, and finished just today (24th). The goal was to replace her current HTPC, catalogued many years ago on GN, which uses an A10-5800K, upgraded MSI GTX 960 Gaming X, and is struggling to operate high framerates.
The A10-5800K was an excellent CPU for the original build (which had no GPU, and later added a 750 Ti), but it’s not so powerful 4 years later. We wanted to pull parts for this build that could be readily found in GN’s lab, without shipping requirements (where avoidable), and without pulling parts that are in active or regression testing use.
Ramping up the video production for 2016 led to some obvious problems – namely, burning through tons of storage. We’ve fully consumed 4TB of video storage this year with what we’re producing, and although that might be a small amount to large video enterprises, it is not insignificant for our operation. We needed a way to handle that data without potentially losing anything that could be important later, and ultimately decided to write a custom Powershell script for automated Handbrake CLI compression routines that execute monthly.
Well, will execute monthly. For now, it’s still catching up and is crunching away on 4000+ video files for 2016.
Thermal cameras have proliferated to a point that people are buying them for use as tech toys, made possible thanks to new prices nearer $200 than the multi-thousand thermal imaging cameras that have long been the norm. Using a thermal camera that connects to a mobile phone eliminates a lot of the cost for such a device, relying on the mobile device’s hardware for post-processing and image cleanup that make the cameras semi-useful. They’re not the most accurate and should never be trusted over a dedicated, proper thermal imaging device, but they’re accurate enough for spot-checking and rapid concepting of testing procedures.
Unfortunately, we’ve seen them used lately as hard data for thermal performance of PC hardware. For all kinds of reasons, this needs to be done with caution. We urged in our EVGA VRM coverage that thermal imaging was not perfect for the task, and later stuck thermal probes directly to the card for more accurate measurements. Even ignoring the factors of emission, transmission, and reflection (today’s topics), using thermal imaging to take temperature measurements of core component temperatures is methodologically flawed. Measuring the case temperature of a laptop or chassis tells us nothing more than that – the temperature of the surface materials, assuming an ideal black body with an emissivity close to 1.0. We’ll talk about that contingency momentarily.
But even so: Pointing a thermal imager at a perfectly black surface and measuring its temperature is telling us the temperature of the surface. Sure, that’s useful for a few things; in laptops, that could be determining if case temperature exceeds the skin temp specification of a particular manufacturer. This is good for validating whether a device might be safe to touch, or for proving that a device is too hot for actual on-lap use. We could also use this information as troubleshooting to help us determine where hotspots are under the hood, potentially useful in very specific cases.
That doesn’t, however, tell us the efficacy of the cooling solution within the computer. For that, we need software to measure the CPU core temperatures, the GPU diode, and potentially other components (PCH and HDD/SSD are less popular, but occasionally important). Further analysis would require direct thermocouple probes mounted to the SMDs of interest, like VRM components or VRAM. Neither of these two examples are equipped with internal sensors that software, and even the host GPU, is capable of reading.
The second card in our “revisit” series – sort of semi-re-reviews – is the GTX 780 Ti from November of 2013, which originally shipped for $700. This was the flagship of the Kepler architecture, followed later by Maxwell architecture on GTX 900 series GPUs, and then the modern Pascal. The 780 Ti was in competition with AMD’s R9 200 series and (a bit later) R9 300 series cards, and was accompanied by the expected 780, 770, and 760 video cards.
Our last revisit looked at the GTX 770 2GB card, and our next one plans to look at an AMD R9 200-series card. For today, we’re revisiting the GTX 780 Ti 3GB card for an analysis of its performance in 2016, as pitted against the modern GTX 1080, 1070, 1060, 1050 Ti, and RX 480, 470, and others.
GN reader ‘Eric’ reached-out to us to loan his Alphacool Eiswolf GPX Pro cooling block, which we’ve now applied to a GTX 1080 Founders Edition card. The Eiswolf build process isn’t too difficult – certainly easier than the tear-down of the average FE card. The Eiswolf GPX Pro has an on-card pump with designated in/out tubes, each terminating in threaded quick release valves that hook into a semi-open loop system. We later purchased an Alphacool Eisbaer for our radiator and CPU cooler, then connected them all together.
The review of the Eiswolf will be posted tomorrow, followed shortly by a look at EK WB’s Predator XLC. For today, we’re just posting the build log that our Patreon backers have helped produce.
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.