We just posted our second part of the Titan Xp Hybrid mod, detailing the build-up process for adding CLCs to the Titan Xp. The process is identical to the one we detailed for the GTX 1080 Ti FE card, since the PCB is effectively equal between the two devices.
For this build, we added thermocouples to the VRAM and VRM components to try and determine if Hybrid mods help or hurt VRAM temperatures (and, with that part of testing done, we have some interesting results). Final testing and benchmarking is being run now, with plans to publish by Monday.
In the meantime, check out part 2 below:
Thanks to GamersNexus reader ‘Grant,’ we were able to obtain a loaner nVidia Titan Xp (2017) card for review and thermal analysis. Grant purchased the card for machine learning and wanted to liquid cool the GPU, which happens to be something with which we’re well-versed. In the process, we’ll be reviewing the Titan Xp from a gaming standpoint, tearing it down, analyzing the PCB & VRM, and building it back into a liquid-cooled card. All the benchmarking is already done, but we’re opening our Titan Xp content string with a tear-down of the card.
Disassembling Founders Edition nVidia graphics cards tends to be a little more tool-intensive than most other GPU tear-downs. NVidia uses 2.0mm & 2.5mm Allen keys to secure the shroud to the baseplate, and then the baseplate to the PCB; additionally, a batch of ~16x 4mm hex heads socket through the PCB and into the baseplate, each of which hosts a small Phillips screw for the backplate.
The disassembly tutorial continues after this video version:
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.”
We moderate comments on a ~24~48 hour cycle. There will be some delay after submitting a comment.