As stated in the video intro, this benchmark contains some cool data that was exciting to work with. We don’t normally accumulate enough data to run historical trend plots across various driver or game revisions, but our initial Destiny 2 pre-launch benchmarks enabled us to compare that data against the game’s official launch. Bridging our pre-launch beta benchmarks with similar testing methods for the Destiny 2 PC launch, including driver changes, makes it easier to analyze the deviation between CPU, driver, and game code optimizations.

Recapping the previous tests, we already ran a wide suite of Destiny 2 benchmarks that included performance scaling tests in PvP multiplayer, campaign/co-op multiplayer, and various levels/worlds in the game. Find some of that content below:

NOTE: Our Destiny 2 CPU benchmark is now live.

Some of our original graphics optimization work also carried forward, allowing us to better pinpoint Depth of Field on Highest as one of the major culprits to AMD’s performance. This has changed somewhat with launch, as you’ll find below.

We’re sticking with FXAA for testing. Bungie ended up removing MSAA entirely, as the technique has been buggy since the beta, and left only SMAA and FXAA in its place.

AMD’s High-Bandwidth Cache Controller protocol is one of the keystones to the Vega architecture, marked by RTG lead Raja Koduri as a personal favorite feature of Vega, and highlighted in previous marketing materials as offering a potential 50% uplift in average FPS when in VRAM-constrained scenarios. With a few driver revisions now behind us, we’re revisiting our Vega 56 hybrid card to benchmark HBCC in A/B fashion, testing in memory-constrained scenarios to determine efficacy in real gaming workloads.

Wolfenstein II: The New Colossus is launching this Friday, and Bethesda have now published the final minimum and recommended specs. Bethesda is touting some PC-focused features like uncapped framerates (as we saw in the Destiny 2 beta, this can also mean “capped above 144”), choice of aspect ratio (4:3, 16:9, 16:10, or 21:9 ultrawide), an FOV slider (70-120), and 4K support.

The New Colossus will use the Vulkan API, following in the footsteps of the notoriously well-optimized DOOM reboot. In our DOOM testing more than a year ago, AMD’s RX 480 benefitted strongly from using Vulkan rather than OpenGL, as did NVIDIA’s 1080 to a lesser degree. Vega is specifically mentioned in this release, and Bethesda claims that with Vulkan they’ve been able to “utilize the power of AMD's Vega graphics chips in ways that were not possible before.” We’ll be publishing GPU tests as soon as possible.

From Bethesda’s site:

The Windows 10 Fall Creators Update (FCU) has reportedly provided performance uplift under specific usage scenarios, most of which center around GPU-bound scenarios with Vega 56 or similar GPUs. We know with relative certainty that FCU has improved performance stability and frametime consistency with adaptive synchronization technologies – Gsync and FreeSync, mostly – and that there may be general GPU-bound performance uplift. Some of this could come down to driver hooks and implementation in Windows, some of it could be GPU or arch-specific. What we haven’t seen much of is CPU-bound tests, attempting to isolate the CPU as the DUT for benchmarking.

These tests look at AMD Ryzen R7 1700 (stock) performance in Windows 10 Creator’s Update (build 1703, ending in 608) versus Windows 10 Fall Creators Update. Our testing can only speak for our testing, as always, and we cannot reasonably draw conclusions across the hardware stack with these benchmarks. The tests are representative of the R7 1700 in CPU-bound scenarios, created by using a GTX 1080 Ti FTW3. Because this is a 1080 Ti FTW3, we have two additional considerations for possible performance uplift (neither of which will be represented herein):

  • - As an nVidia GPU, it is possible that driver/OS behavior will be different than with an AMD GPU
  • - As a 1080 Ti FTW3, it is possible and likely that GPU-bound performance – which we aren’t testing – would exhibit uplift where this testing does not

Our results are not conclusive of the entirety of FCU, and cannot be used to draw wide-reaching conclusions about multiple hardware configurations. Our objective is to start pinpointing performance uplift, and from what combination of components that uplift can be derived. Most reports we have seen have spotted uplift with 1070 or Vega 56 GPUs, which would indicate GPU-bound performance increases (particularly because said reports show bigger gains at higher resolutions). We also cannot yet speak to performance change on Intel CPUs.

Hardware news for the last week includes discussion on an inadvertent NZXT H700i case unveil (with “machine learning,” apparently), Ryzen/Vega APU, Vega partner card availability, and Coffee Lake availability.

Minor news items include the AMD AGESA 1.0.0.7 update to support Raven Ridge & Pinnacle Ridge, Noctua’s Chromax fans, and some VR news – like Oculus dropping its prices – and the Pimax 8K VR configuration.

Find the video and show notes below:

This episode of Ask GN was filmed a few days ago, but we ended up with so much content (like the H500P review and Vega 64 Strix PCB analysis) that we postponed its publication. The episode tackles popular topics of thermals and thermal testing, which have recently received more public interest, and also covers some top-level discussion of power, thermals, and electricity.

We spend most of the time discussing motherboard differences -- a story we've been harping on since January -- and how different board voltages affect CPUs in different ways. The rest of the intro is spent explaining thermal testing difficulties and challenges, and how we can best normalize for those in review content. The timestamps are below the video embed:

Following-up our tear-down of the ASUS ROG Strix Vega 64 graphics card, Buildzoid of Actually Hardcore Overclocking now visits the PCB for an in-depth VRM & PCB analysis. The big question was whether ASUS could reasonably outdo AMD's reference design, which is shockingly good for a card with such a bad cooler. "Reasonably," in this sentence, means "within reasonable cost" -- there's not much price-to-performance headroom with Vega, so any custom cards will have to keep MSRP as low as possible while still iterating on the cooler.

The PCB & VRM analysis is below, but we're still on hold for performance testing. As of right now, we are waiting on ASUS to finalize its VBIOS for best compatibility with AMD's drivers. It seems that there is some more discussion between AIB partners and AMD for this generation, which is introducing a bit of latency on launches. For now, here's the PCB analysis -- timestamps are on the left-side of the video:

We’re testing gaming while streaming on the R5 1500X & i5-8400 today, both CPUs that cost the same (MSRP is about $190) and appeal to similar markets. Difficulties stemming from stream benchmarking make it functionally impossible to standardize. CPU changes drastically impact performance during our streaming + gaming benchmarks, which means that each CPU test falls closer to a head-to-head than an overall benchmark. Moving between R5s and R7s, for instance, completely changes the settings required to produce a playable game + stream experience – and that’s good. That’s what we want. The fact that settings have to be tuned nearly on a per-tier basis means that we’re min-maxing what the CPUs can give us, and that’s what a user would do. Creating what is effectively a synthetic test is useful for outright component comparison, but loses resolution as a viable test candidate.

The trouble comes with lowering the bar: As lower-end CPUs are accommodated and tested for, higher-end components perform at lower-than-maximum throughput, but are capped in benchmark measurements. It is impossible, for example, to encode greater than 100% of frames to stream. That will always be a limitation. At this point, you either declare the CPU as functional for that type of encoding, or you constrict performance with heavier duty encoding workloads.

H264 ranges from Ultrafast to Slowest settings, with facets in between identified as Superfast, Veryfast, Faster, Fast, and Medium. As encoding speed approaches the Slow settings, quality enters into “placebo” territory. Quality at some point becomes indistinguishable from faster encoding settings, despite significantly more strain placed on the processor. The goal of the streamer is to achieve a constant framerate output – whether that’s 30FPS or 60FPS – while also maintaining a playable player-side framerate. We test both halves of the equation in our streaming benchmarks, looking at encode output and player output with equal discernment.

We’ve already sent off the information contained in this video to Buildzoid, who has produced a PCB & VRM analysis of the ROG Strix Vega 64 by ASUS. That content will go live within the next few days, and will talk about whether the Strix card manages to outmatch AMD’s already-excellent reference PCB design for Vega. Stay tuned for that.

In the meantime, the below is a discussion of the cooling solution and disassembly process for the ASUS ROG Strix Vega 64 card. For cooling, ASUS is using a similar triple-fan solution that we highly praised in its 1080 Ti Strix model (remarkable for its noise-normalized cooling performance), along with similar heatsink layout.

Learn more here:

We’re winding-down coverage of Vega, at this point, but we’ve got a couple more curiosities to explore. This content piece looks at a mix of clock scalability for Vega across a few key clocks (for core and HBM2), and hopes to constrain for a CU difference, to some extent. We obviously can’t fully control down to the shader level (as CUs carry more than just shaders), but we can get close to it. Note that the video content does generally refer to the V56 & V64 difference as one of shaders, but more than shaders are contained in the CUs.

In our initial AMD shader comparison between Vega 56 and Vega 64, we saw nearly identical performance between the cards when clock-matched to roughly 1580~1590MHz core and 945MHz HBM2. We’re now exploring performance across a range of frequency settings, from ~1400MHz core to ~1660MHz core, and from 800MHz HBM2 to ~1050MHz HBM2.

This content piece was originally written and filmed about ten days ago, ready to go live, but we then decided to put a hold on the content and update it. Against initial plans, we ended up flashing V64 VBIOS onto the V56 to give us more voltage headroom for HBM2 clocks, allowing us to get up to 1020MHz easily on V56. There might be room in there for a bit more of an OC, but 1020MHz proved stable on both our V64 and V56 cards, making it easy to test the two comparatively.

We moderate comments on a ~24~48 hour cycle. There will be some delay after submitting a comment.

Advertisement:

  VigLink badge