Internet cafes and gaming centers probably aren’t a market segment most would recognize in the US, but they’re popular in other parts of the world--in particular, Asia--and ASUS seems to target that segment with the purpose-built Expedition A320M Gaming motherboard.
The entry-level AM4 board uses the low-end A320 chipset, and offers features that appear to identify with the rigors of crowded public places, such as iCafes and libraries. One such feature is the moisture-resistant coating on the motherboard, intended to protect against higher humidity environments. This is particularly useful in places like Taiwan, where humidity is high enough to cause corrosion on some components (that we’ve seen in person, no less). Additionally, the board has certain anti-theft features to help curb theft of memory modules and GPUs.
Our Destiny 2 GPU benchmark highlighted massive performance uplift vs. beta on some devices, upwards of 50% on Vega, but was conducted in largely GPU-constrained scenarios. For this content piece, we’ll be exploring the opposite: CPU-constrained scenarios to benchmark Destiny 2 performance on AMD Ryzen and Intel Kaby/Coffee Lake parts, including the R7 1700, R5 1600X, R3 1200, and i7-7700K, i5-7600K, i3-8350K, and G4560.
Most of our test notes have already been recapped in the GPU benchmark, and won’t be fully repeated. Again, we ran a wide spread of tests during the beta, which will be informing our analysis for the Destiny 2 launch benchmarks. Find the previous content below:
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:
- Destiny 2 Beta GPU Benchmark (+ graphics optimization guide, PvP scalability)
- Destiny 2 Beta CPU Benchmark (soon replaced by our Destiny 2 launch CPU bench)
- Destiny 2 texture comparison
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 184.108.40.206 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 moderate comments on a ~24~48 hour cycle. There will be some delay after submitting a comment.