The RX 580, as we learned in the review process, isn’t all that different from its origins in the RX 480. The primary difference is in voltage and frequency afforded to the GPU proper, with other changes manifesting in maturation of the process over the past year of manufacturing. This means most optimizations are relegated to power (when idle – not under load) and frequency headroom. Gains on the new cards are not from anything fancy – just driving more power through under load.
Still, we were curious as to whether AMD’s drivers would permit cross-RX series multi-GPU. We decided to throw an MSI RX 580 Gaming X and MSI RX 480 Gaming X into a configuration to get things close, then see what’d happen.
The short of it is that this works. There is no explicit inhibitor built in to forbid users from running CrossFire with RX 400 and RX 500 series cards, as long as you’re doing 470/570 or 480/580. The GPU is the same, and frequency will just be matched to the slowest card, for the most part.
We think this will be a common use case, too. It makes sense: If you’re a current owner of an RX 480 and have been considering CrossFire (though we didn’t necessarily recommend it in previous content), the RX 580 will make the most sense for a secondary GPU. Well, primary, really – but you get the idea. The RX 400 series cards will see EOL and cease production in short order, if not already, which means that prices will stagnate and then skyrocket. That’s just what retailers do. Buying a 580, then, makes far more sense if dying for a CrossFire configuration, and you could even move the 580 to the top slot for best performance in single-GPU scenarios.
Our third and final interview featuring Scott Wasson, current AMD RTG team member and former EIC of Tech Report, has just gone live with information on GPU architecture. This video focuses more on a handful of reader and viewer questions, pooled largely from our Patreon backer discord, with the big item being “GPU IPC.” Patreon backer “Streetguru” submitted the question, asking why a ~1300~1400MHz RX 480 could perform comparably to an ~1800MHz GTX 1060 card. It’s a good question – it’s easy to say “architecture,” but to learn more about the why aspect, we turned to Wasson.
The main event starts at 1:04, with some follow-up questions scattered throughout Wasson’s explanation. We talk about pipeline stage length and its impact on performance, wider versus narrower machines with frequencies that match, and voltage “spent” on each stage.
We’ll leave this content piece primarily to video, as Wasson does a good job to convey the information quickly.
In light of both the House and Senate voting to reverse forthcoming privacy regulations, interest in privacy measures that can be taken by the end-user are no doubt piqued. While there is no comprehensive solution to end all privacy woes—outside of, you know, stringent privacy laws—there are a few different steps that can be taken. A VPN (Virtual Private Network) is the big one, although they come with a few of their own caveats. The Tor software offers the most ways to anonymize a user’s online presence and more, although it can be involved. Smaller actions include adjusting DNS settings and using the HTTPS Everywhere extension.
Read on, as we will delve into these in a bit more detail. This guide serves as a tutorial to setting up a VPN and protecting your privacy online.
Prior to the Ryzen launch, we discovered an issue with GTA V testing that would cause high-speed CPUs of a particular variety to stutter when achieving high framerates. Our first video didn’t conclude with a root cause, but we now believe the game is running into engine constraints – present on other RAGE games – that trigger choppy behavior on those CPUs. Originally, we only saw this on the best i5s – older gen i5 CPUs were not affected, as they were not fast enough to exceed the framerate limiter in GTA V (~187FPS, or thereabouts), and so never encountered the stutters. The newest i5 CPUs, like the 7600K and 6600K, would post high framerates, but lose consistency in frametimes. As an end user, the solution would be (interestingly) to increase your graphics quality, resolution, or otherwise bring FPS to around the 120-165 mark.
Then Ryzen came out, and then Ryzen 5 came out. With R5, we encountered a few stutters in GTA V when SMT was enabled and when the CPU was operating under conditions permitting the CPU to achieve the same high framerates as Intel Core i5-7600K CPUs. To better illustrate, we can actually turn down graphics settings to a point of forcing framerates to the max on 4C/8T R5 CPUs, relinquishing some of the performance constraint, and then encounter hard stuttering. In short: A higher framerate overall would result in a much worse experience for the player, both on i5 and R5 CPUs. The 4C/8T R5 CPUs exhibited this same stutter performance (as i5 CPUs) most heavily when SMT was disabled, at which point we spit out a graph like this:
This content marks the beginning of our in-depth VR testing efforts, part of an ongoing test pattern that hopes to determine distinct advantages and disadvantages on today’s hardware. VR hasn’t been a high-performance content topic for us, but we believe it’s an important one for this release of Kaby Lake & Ryzen CPUs: Both brands have boasted high VR performance, “VR Ready” tags, and other marketing that hasn’t been validated – mostly because it’s hard to do so. We’re leveraging a hardware capture rig to intercept frames to the headsets, FCAT VR, and a suite of five games across the Oculus Rift & HTC Vive to benchmark the R7 1700 vs. i7-7700K. This testing includes benchmarks at stock and overclocked configurations, totaling four devices under test (DUT) across two headsets and five games. Although this is “just” 20 total tests (with multiple passes), the process takes significantly longer than testing our entire suite of GPUs. Executing 20 of these VR benchmarks, ignoring parity tests, takes several days. We could do the same count for a GPU suite and have it done in a day.
VR benchmarking is hard, as it turns out, and there are a number of imperfections in any existing test methodology for VR. We’ve got a good solution to testing that has proven reliable, but in no way do we claim that perfect. Fortunately, by combining hardware and software capture, we’re able to validate numbers for each test pass. Using multiple test passes over the past five months of working with FCAT VR, we’ve also been able to build-up a database that gives us a clear margin of error; to this end, we’ve added error bars to the bar graphs to help illustrate when results are within usual variance.
We’ve received a ton of positive feedback on our i5-2500K revisit, and we’ve received a similar amount of questions about including overclocked i7-2600K numbers in our benchmark charts. The solution is obvious: a full 2600K revisit using our modern benchmark course. As demonstrated with the 2500K, old K-SKU Sandy Bridge CPUs had impressive overclocking capacity--partly thanks to a better thermal solution than what Intel offers today--but the stock i7-2600K regularly outperformed our 4.5GHz 2500K in some tests. Synthetic benchmarks and games like Watch Dogs 2, both of which take advantage of high thread counts, are included in those tests showing favor to the 2600K.1
Although we ended the 2500K review with the conclusion that now is a good time to start thinking about an upgrade, i7 CPUs are considered as more future-proof. Today, we’re testing that conception to see how it holds up to 2017’s test suite. With Ryzen 7 now fully released, considering 2600K owners are likely looking (price-wise) at a 7700K ($345) or 1700 ($330), it makes sense to revisit SNB one more time.
Note: For anyone who saw our recent Ryzen Revisit coverage, you know that there are some fairly important changes to Total War: Warhammer and Battlefield 1 that impacted Ryzen, and could also impact Intel. We have not fully retested our suite with these changes yet, and this content was written prior to the Ryzen revisit. Still, we’re including some updated numbers in here – but it’s not really the focus of the content, we’re more interested now in seeing how the i7-2600K performs in today’s games, especially with an overclock.
The playful Nintendo noises emitted from our Switch came as somewhat of a surprise following an extensive tear-down and re-assembly process. Alas, the console does still work, and we left behind breadcrumbs of our dissection within the body of the Switch: a pair of thermocouples mounted to the top-center of the SOC package and one memory package. We can’t get software-level diode readings of the SOC’s internal sensors, particularly given the locked-down nature of a console like Nintendo’s, and so thermal probes allow us the best insight as to the console’s temperature performance. As a general rule, thermal performance is hard to keep in perspective without a comparative metric, so we need something else. That’ll be noise, for this one; we’re testing dBA output of the fan versus an effective tCase on the SOC to determine how the fan ramps.
There’s no good way to measure the Switch’s GPU frequency without hooking up equipment we don’t have, so we won’t be able to plot a frequency versus temperature/time chart. Instead, we’re looking at temperature versus noise, then using ad-hoc testing to observationally determine framerate response to various logged temperatures. Until a point at which we’ve developed tools for monitoring console FPS externally, this is the best combination of procedures we can muster.
We’ve fixed the GTX 1080 Ti Founders Edition ($700) card. As stated in the initial review, the card performed reasonably close to nVidia’s “35% > 1080” metric when at 4K resolutions, but generally fell closer to 25-30% faster at 4K. That’s really not bad – but it could be better, even with the reference PCB. It’s the cooler that’s holding nVidia’s card back, as seems to be the trend given GPU Boost 3.0 + FE cooler designs. A reference card is more versatile for deployment to the SIs and wider channel, but for our audience, we can rebuild it. We have the technology.
“Technology,” here, mostly meaning “propylene glycol.”
When we first began benchmarking Ryzen CPUs, we already had a suspicion that disabling simultaneous multithreading might give a performance boost in games, mirroring the effects of disabling hyperthreading (Intel’s specific twist on SMT) when it was first introduced. Although hyperthreading now has a generally positive effect in our benchmarks, there was a time when it wasn’t accounted for by developers—presumably partly related to what’s happening to AMD now.
In fact, turning SMT off offered relatively minor gaming performance increases outside of Total War: Warhammer—but any increase at all is notable when turning off a feature that’s designed to be positive. Throughout our testing, the most dramatic change in results we saw were from overclocking, specifically on the low stock frequency R7 1700 ($330). This led many readers to ask questions like “why didn’t you test with an overclock and SMT disabled at the same time?” and “how much is Intel paying you?” to which the answers are “time constraints” and “not enough, apparently,” since we’ve now performed those tests. Testing a CPU takes a lot of time. Now, with more time to work on Ryzen, we’ve finally begun revisiting some EFI, clock behavior, and SMT tests.
As with any new technology, the early days of Ryzen have been filled with a number of quirks as manufacturers and developers scramble to support AMD’s new architecture.
For optimal performance, AMD has asked reviewers to update to the latest BIOS version and to set Windows to “high performance” mode, which raises the minimum processor state to its base frequency (normally, the CPU would downclock when idle). These are both reasonable allowances to make for new hardware, although high-performance mode should only be a temporary fix. More on that later, though we’ve already explained it in the R7 1700 review.
This is quick-and-dirty testing. This is the kind of information we normally keep internal for research as we build a test platform, as it's never polished enough to publish and primarily informs our reviewing efforts. Given the young age of Ryzen, we're publishing our findings just to add data to a growing pool. More data points should hopefully assist other reviewers and manufacturers in researching performance “anomalies” or differences.
The below is comprised of early numbers we ran on performance vs. balanced mode, Gigabyte BIOS revisions, ASUS' board, and clock behavior when under various boost states. Methodology won't be discussed here, as it's really not any different from our 1700 and 1800X review, other than toggling of the various A/B test states defined in headers below.