• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

AMD Ryzen Thread: Affordable Core Act

PnCIa

Member
A really interesting video that helps to explain some of the uneven game performance on Ryzen and why AMD's GPUs seem less affected by it:

AMD vs NV Drivers: A Brief History and Understanding Scheduling & CPU Overhead

Hopefully this is something that NVIDIA will be working to improve.
Now that was an interesting video. Thanks!

I just realized that he mentioned AdoredTV in a positive light.
I know that Adored gets a good amount of shit from some well-known users here for trying to put AMD in a positive light, but its good to know that he apparently does some good work.
 
Tuxfool and SRG01, thank you both for linking these:

http://www.neogaf.com/forum/showpost.php?p=233058875&postcount=2219

http://www.neogaf.com/forum/showpost.php?p=233199257&postcount=2291


Spyshagg and Sinistral with a reasoned response on CPUs/GPUs at a base level, and a primary purpose of the CCX approach:

http://www.neogaf.com/forum/showpost.php?p=233106284&postcount=2238



A really interesting video that helps to explain some of the uneven game performance on Ryzen and why AMD's GPUs seem less affected by it:

AMD vs NV Drivers: A Brief History and Understanding Scheduling & CPU Overhead

Hopefully this is something that NVIDIA will be working to improve.
Essentially all of this is accurate, and I'd urge everyone (especially those unfamiliar with the topic) to watch the video.

It's a good, easily understood synopsis presented in a way that isn't heavily skewed by bias.

At the risk of sounding pompous or full of shit, I've known all of this and have argued it for years. Fairly certain *many* others here have also been aware so that isn't a stretch or in any way special.

I haven't always communicated the points well, but it has been frustrating to continuously see technically inclined people disregard what has been readily available info due to their allegiance to specific hardware brands or other reasons. The amount of arguments you see that negate the facts of the past few GPU generations and how things have been dictated can be dizzying.

Two points I've mentioned often have been the lowered CPU overhead on current AMD cards in DX11 and earlier games that have been coded to spread their load a bit, and the efforts of Nvidia that have lead to delayed, discounted or "discontinued" DX12 versions of titles. Owing in part to the DX11 push that plays on several years of their driver receiving optimisations and workarounds (sharp business tactic to hold until post-Volta architectures are here).

As mentioned in the video you lose much of that work and the advantages it provides as you move to closer to more capable DX12 and Vulkan implementations. While its use is now starting to ramp up, not every game can be made to run on Unreal Engine 4...

Another thing that has always fascinated me is what Fermi would have been like if it were scaled and evolved to include all recent feature support and graphics techniques. If not exactly Fermi itself, at least a Fermi-like arch. No, not GCN.

The video is also correct about Polaris' efforts at reducing CPU overhead, in part by doing more per-cycle and calling on the CPU less. IIRC, he stated Polaris solves the issues of over-tesselation (?). Their cards are not quite there yet, though AMD Vega should be more capable of addressing that through better implementation and more robust culling.

You can only do so much to get around scheduling limitations, but it's going to be interesting to see Vega run games such as Project Cars.

It will also be interesting to see whether Nvidia Volta does in fact return to a more parallel arch with "proper" DX12 support, and no need for drivers to enable non-existing asynchronous capabilities. In essence both vendors' GPUs should more closely "mirror" each other -at least in terms of features- as they offset each other's weaknesses, in an effort to better support current APIs, engines and rendering techniques.

I also look forward to a number of users' reactions once Volta arrives.


Apologies for the drawn out response, typos and any tangents. As for the current GPU-talk direction of the thread, it's important we leave aside grafx-card-warzzz and stay more closely to the relevant GPU software optimisations as it relates to Intel and AMD CPUs.
 

Paragon

Member
·feist·;233219227 said:
Essentially all of this is accurate, and I'd urge everyone (especially those unfamiliar with the topic) to watch the video.
It's a good, easily understood synopsis presented in a way that isn't heavily skewed by bias.
At the risk of sounding pompous or full of shit, I've known all of this and have argued it for years. Fairly certain *many* others here have also been aware so that isn't a stretch or in any way special.
I was aware of the situation with NVIDIA having a multi-threaded DX11 driver while AMD's was not, but I did not know that they didn't just support driver command lists, but that the "threaded optimization" feature was actually the driver 'translating' single-threaded DX11 calls into multi-threaded calls.
I had also not considered that, if the game is sufficiently multithreaded, AMD GPUs could potentially perform better if a single thread is dedicated to only handling draw calls and none of the other game logic. Seems obvious in retrospect.

·feist·;233219227 said:
It will also be interesting to see whether Nvidia Volta does in fact return to a more parallel arch with "proper" DX12 support, and no need for drivers to enable non-existing asynchronous capabilities. In essence both vendors' GPUs should more closely "mirror" each other -at least in terms of features- as they offset each other's weaknesses, in an effort to better support current APIs, engines and rendering techniques.
I also look forward to a number of users' reactions once Volta arrives.
Indeed.
I suspect that the direction Volta takes is going to determine how much NVIDIA are going to focus on optimizing their driver for Ryzen.

Though it's easy for people to dismiss the idea altogether with statements like: "Why would NVIDIA optimize for a competitor's product?" NVIDIA are in the business of selling GPUs, not CPUs.
If they can sell more GPUs to people with Ryzen systems instead of having them jump ship to AMD, they'll do the work.
 
Indeed.
I suspect that the direction Volta takes is going to determine how much NVIDIA are going to focus on optimizing their driver for Ryzen.

Though it's easy for people to dismiss the idea altogether with statements like: "Why would NVIDIA optimize for a competitor's product?" NVIDIA are in the business of selling GPUs, not CPUs.
If they can sell more GPUs to people with Ryzen systems instead of having them jump ship to AMD, they'll do the work.

I don't really get that mentality at all. I mean Nvidia more or less timed the release of the 1080 Ti to coincide with Ryzen's release. They are basically telling every Ryzen buyer that they should also buy a nice 1080 Ti go to with their new Ryzen build. Nvidia wants to sell GPUs to everyone, regardless of whether they own Intel or AMD CPUs.

The apparent problems with their driver seem little different from the performance problems games have on Ryzen. It's unlikely that Nvidia had any idea of how Ryzen was going to be performing until after it was released either, it's not as if AMD was likely to be giving engineering samples to Nvidia or something.

So Nvidia has only just now seen Ryzen at the same time the first consumers did, and drivers aren't built in a day. Nvidia is probably working very furiously to figure out how to optimize their drivers for Ryzen's peculiar x86 implementation but no one should be pretending this is easy since Windows can't even seem to figure it out right now.
 
A really interesting video that helps to explain some of the uneven game performance on Ryzen and why AMD's GPUs seem less affected by it:

AMD vs NV Drivers: A Brief History and Understanding Scheduling & CPU Overhead

Hopefully this is something that NVIDIA will be working to improve.

I've been subscribing to NerdTechGasm from when he first started and although he doesn't post that often, his videos are always very informative and explained clearly.

NerdTechGasm said:
Nvidia GPUs have a higher CPU overhead and use more CPU cycles but can potentially have much higher DX11 draw-calls if there is idling CPU resources.

Inversely, AMD's drivers are more direct to the GPU but are very weak when rendering thread bottlenecks.

I've known for a while that Nvidia's thread scheduler is software based and AMD's is on-chip, but interesting for those that didn't.

He also touches on why Ryzen can suffer performance hits because of Nvidia's scheduler, which is not optimised for a new CPU arch.
 
MSI and ASRock appear to be continuing their own XMP memory compatibility improvements, apart from the updates passed on by AMD. Both ASRock's X370 Taichi and X370 Fatality Pro have received ~3-4 XMP compatibility updates since launch.



RedGamingTech —— BIOS Update Drastically Increases Ryzen’s Game Performance | Benchmarking

Salazar Studio —— Can a BIOS Update Increase FPS for AMD Ryzen PCs?


bios-gtae4q0p.png
TUv3a0p.jpg
MB8h5pt.jpg
Note, this would be separate from the Geforce-Ryzen driver-related performance issues seen in some games.

More testing from diverse sources is needed.



I was aware of the situation with NVIDIA having a multi-threaded DX11 driver while AMD's was not, but I did not know that they didn't just support driver command lists, but that the "threaded optimization" feature was actually the driver 'translating' single-threaded DX11 calls into multi-threaded calls.
I had also not considered that, if the game is sufficiently multithreaded, AMD GPUs could potentially perform better if a single thread is dedicated to only handling draw calls and none of the other game logic. Seems obvious in retrospect.
Nvidia's driver is a good match to a family of parts which are largely more serial in nature than GCN. It's obviously one of the reasons a number of titles perform better in certain aspects on a low IPC CPU like the Construction Core family (especially BD through PD+), and low clocked CPUs like the Cat Core family, Intel Atom or similar.

The recent drawback being what's viewed as a stifling of DX12 progress in its early days for reasons that stand to benefit Nvidia financially. That's a subject for another thread topic, though.


Indeed.
I suspect that the direction Volta takes is going to determine how much NVIDIA are going to focus on optimizing their driver for Ryzen.

Though it's easy for people to dismiss the idea altogether with statements like: "Why would NVIDIA optimize for a competitor's product?" NVIDIA are in the business of selling GPUs, not CPUs.
If they can sell more GPUs to people with Ryzen systems instead of having them jump ship to AMD, they'll do the work.
Agreed. They're a business. Potential sales are more important than "us vs them." Similarly, it's why Microsoft are looking more into the viability of extended Windows support on ARM.

Again, good post. I'll be adding that clip to the resources or videos section of the OP as a reference.
 

Ploid 3.0

Member
A really interesting video that helps to explain some of the uneven game performance on Ryzen and why AMD's GPUs seem less affected by it:

AMD vs NV Drivers: A Brief History and Understanding Scheduling & CPU Overhead

Hopefully this is something that NVIDIA will be working to improve.

This was so interesting. I love this kind of content. Good thing amd got that console gig, nvidia is still trying to hold gaming back though. I had no idea the fiercest gaming war was pc. GPU and CPU.
 
If you guys want a good explanation of the new AotS patch and the Ryzen improvements, here's a good explanation of it: https://twitter.com/FioraAeterna/status/847472586581712897

Actually, the issue in that Ashes of the Singularity benchmark is that they were using instructions that bypassed cache access by using instructions that are specifically designed not to be reused again.

https://twitter.com/FioraAeterna/status/847472309010964481

For an explanation of how those instructions work:

http://stackoverflow.com/questions/37070/what-is-the-meaning-of-non-temporal-memory-accesses-in-x86

Used properly it could be faster, but like a lot of things it is never universally applicable.

This is awesome, thanks for posting these! I hadn't seen these tweets even though I've been following her on Twitter.

A really interesting video that helps to explain some of the uneven game performance on Ryzen and why AMD's GPUs seem less affected by it:

AMD vs NV Drivers: A Brief History and Understanding Scheduling & CPU Overhead

Hopefully this is something that NVIDIA will be working to improve.

This is an amazing video, thanks for posting!

·feist·;233255351 said:
MSI and ASRock appear to be continuing their own XMP memory compatibility improvements, apart from the updates passed on by AMD. Both ASRock's X370 Taichi and X370 Fatality Pro have received ~3-4 XMP compatibility updates since launch.

RedGamingTech —— BIOS Update Drastically Increases Ryzen's Game Performance | Benchmarking

Salazar Studio —— Can a BIOS Update Increase FPS for AMD Ryzen PCs?


Note, this would be separate from the Geforce-Ryzen driver-related performance issues seen in some games.

More testing from diverse sources is needed.

Those are some really awesome gains so far, thanks for posting!

I would love to build an MATX or MITX Ryzen system in the future, I'm leaning more towards an MATX one so I can have a second expansion slot however a large portion of the SFF cases I've seen that I like have been MITX ones, however the MATX Inwin 301 is such a lovely case!

The COOLEST mATX Case Yet! - HardwareCanucks
 

dr_rus

Member
I've been subscribing to NerdTechGasm from when he first started and although he doesn't post that often, his videos are always very informative and explained clearly.

I've known for a while that Nvidia's thread scheduler is software based and AMD's is on-chip, but interesting for those that didn't.

He also touches on why Ryzen can suffer performance hits because of Nvidia's scheduler, which is not optimised for a new CPU arch.

This was so interesting. I love this kind of content. Good thing amd got that console gig, nvidia is still trying to hold gaming back though. I had no idea the fiercest gaming war was pc. GPU and CPU.

This is an amazing video, thanks for posting!

That was a great video. Thanks for sharing it. Explained quite a complex subject well, clearly, concisely and really made it simple to follow.


This guy have approximately zero understanding of what he's even talking about in this video.

Don't trust me? Then listen to these guys: https://forum.beyond3d.com/posts/1974379/
 
Total War Warhammer Ryzen performance patch:


Steam Community —— Total War: WARHAMMER - Bretonnia Patch Live Now

Hardware.fr —— Total War Warhammer for Ryzen

Google Translate:

Last week, Creative Assembly released its patch "Bretonnia" for Total War Warhammer. Although the releases notes don't indicate it, we noted that this version brings a net performance gain compared to the previous version on Ryzen:

tww1iur1w.png


We notice a fairly large gain, about 10% on the three Ryzen (we did not notice any gain for the Intel processors), which allows the 1800X to pass the 6900K of a hair on this title. In any case, that a patch improves performance for a new processor is not new, even if the thing is rarer than you think.

It is interesting to compare the behavior of the two versions of this game according to factors like the SMT and the Core Parking:

tww2fzovi.png


We will not go into detail on the Core Parking question (see this page ), but the change in behavior is significant here: with version 1.6.0, we recover the same performance that we obtained by disabling SMT, which suggests that Total War Warhammer did not correctly detect SMT on Ryzen.

This is not the only title to have this problem, we had the opportunity to point a similar bug under F1 2016 which considers Ryzen as a 16-core processor without "HyperThreading", which impacts its way of distributing its threads.

We have updated the performances under Total War for the Ryzen 7 in our two articles, we will point out that in addition to F1 2016 (which is still waiting for the patch!), Another title has this specific behavior (Significant drop in performance that is not compensated by the use of the "Performance" mode under Windows or the deactivation of the Core Parking): Watch Dogs 2!

tww3eroa4.png



F1 2016 un-patched improvements:
http://neogaf.com/forum/showpost.php?p=232080327&postcount=1810
 
Heads up potential Ryzen buyers....Microcenter is offering $100 off Motherboard bundles with the Ryzen 1700x right now, if you happen to live close to one. This is up $70 from their typical bundle price, which makes the 1700x basically $299, or an extremely solid deal.

I'm extremely tempted now. Motherboard availability is a crapshoot atm however (mostly B350 boards available), so ymmv. If this deal is still going tomorrow, I may break down and grab one.
 
This appears to be one of the first reviews of the Ryzen 5 1600, it looks awesome!

First full review of AMD Ryzen 5 1600 is here

This guy have approximately zero understanding of what he's even talking about in this video.

Don't trust me? Then listen to these guys: https://forum.beyond3d.com/posts/1974379/

I'm familiar with some of the things mentioned early in the video as I've researched them before so I was surprised to see someone explaining them to people, but some of the things later are questionable, could you please elaborate on where else he was wrong?
 

dr_rus

Member
At least explain why, which would be more helpful.

And 'these guys' is just one unknown poster calling him out on it, who then seems to agree with him about the software scheduler?

There's a link in that one guy's post which goes in pretty much a lot of details on how NV intra-warp scheduling operates at the moment.

The key takeaway here is that there is no additional CPU load when running shaders on NV cards as this load happens when the shaders are being loaded into the (GPU) driver - which is happening during the game's start / level load and which is where shader cache comes into play on 2nd+ game's start / level load making this whole thing basically non-existent from a practical perspective.

For a more detailed understanding of what changed between Tesla/Fermi and Kepler/Paxwell in scheduling one must first understand that there's several schedulers in play when GPU is executing shader code.

One is managing the API side commands submission, and this scheduler is purely software on all h/w. This is where DX11 and DX12 differs most. This is also why running D3D12 multiengine ("async compute") may result in higher CPU overhead as the API must submit several queues instead of one which takes CPU resources (this is one of possible reasons why async compute may result in a performance loss on some system configurations).

Another is managing the command streams submitted from API into the driver+GPU. This one is usually called "global thread scheduler" or something along these lines and it's s/w+h/w on all GPUs I'm aware of (that's pretty much what AMD calls HWS/ACE). That's what the guy on the video is talking about and this is where he's wrong because all modern GPUs have such global scheduling done in a similar fashion which is basically "some h/w + s/w control and hints from the driver". Whatever changes here happened between Fermi and Kepler made this scheduler more advanced in h/w if anything (Kepler's HyperQ is what was added on this level, for example), not moved it into s/w.

Then there's the lowest scheduling level which happens in each SM/CU and determines which commands from active warps / waves gets to be executed in the next time slot. This is the level where the changes between Fermi and Kepler+ happened. Tesla and Fermi architectures (and GCN up till now) had some complex h/w logic residing in each SM which was able to decide what commands from active warps should be executed next (which lead to Fermi being a bit OOO on this level of execution). This logic was stripped in Kepler and Paxwell in favor of static stream compilation hints performed when submitting shaders to the driver/GPU. This made SM h/w a lot simpler (which partially explain the gain in SP numbers between Fermi and Kepler, for example) and saved a crap load of power consumption while the execution efficiency went up actually as static s/w compilation is in fact producing superior command streams than what h/w SM schedulers were able to create on the fly, in process of shader execution.

This lowest SM level have nothing to do with any API as all GPUs function pretty much in the same way here in DX11, DX12, DX9, OpenGL, Vulkan, CUDA - whatever. It also can't produce any additional CPU load in process of actual execution as the command streams are being compiled for execution prior to them getting into the second "global" scheduling level. It may affect game's loading time or level loading time - but this is why NV introduced shader cache several years ago which is basically a storage of already compiled command streams meaning that even this additional CPU load is non-existing when you're launching a game for 2nd+ time.

On the actual reason of why there are some strange results on NV h/w on Ryzen in DX12 - again, B3D guys are correct in saying that this is most likely a result of NV driver suffering more from Ryzen specific architecture issues because NV's driver is a lot more multithreaded in the first place. Considering that NV spent the last 10 or so years optimizing their driver for Intel multicore CPUs it's completely reasonable to expect issues on a different multicore CPU architectures - issues, which will most likely be fixed in future driver updates.
 
There's a link in that one guy's post which goes in pretty much a lot of details on how NV intra-warp scheduling operates at the moment.

The key takeaway here is that there is no additional CPU load when running shaders on NV cards as this load happens when the shaders are being loaded into the (GPU) driver - which is happening during the game's start / level load and which is where shader cache comes into play on 2nd+ game's start / level load making this whole thing basically non-existent from a practical perspective.

For a more detailed understanding of what changed between Tesla/Fermi and Kepler/Paxwell in scheduling one must first understand that there's several schedulers in play when GPU is executing shader code.

One is managing the API side commands submission, and this scheduler is purely software on all h/w. This is where DX11 and DX12 differs most. This is also why running D3D12 multiengine ("async compute") may result in higher CPU overhead as the API must submit several queues instead of one which takes CPU resources (this is one of possible reasons why async compute may result in a performance loss on some system configurations).

Another is managing the command streams submitted from API into the driver+GPU. This one is usually called "global thread scheduler" or something along these lines and it's s/w+h/w on all GPUs I'm aware of (that's pretty much what AMD calls HWS/ACE). That's what the guy on the video is talking about and this is where he's wrong because all modern GPUs have such global scheduling done in a similar fashion which is basically "some h/w + s/w control and hints from the driver". Whatever changes here happened between Fermi and Kepler made this scheduler more advanced in h/w if anything (Kepler's HyperQ is what was added on this level, for example), not moved it into s/w.

Then there's the lowest scheduling level which happens in each SM/CU and determines which commands from active warps / waves gets to be executed in the next time slot. This is the level where the changes between Fermi and Kepler+ happened. Tesla and Fermi architectures (and GCN up till now) had some complex h/w logic residing in each SM which was able to decide what commands from active warps should be executed next (which lead to Fermi being a bit OOO on this level of execution). This logic was stripped in Kepler and Paxwell in favor of static stream compilation hints performed when submitting shaders to the driver/GPU. This made SM h/w a lot simpler (which partially explain the gain in SP numbers between Fermi and Kepler, for example) and saved a crap load of power consumption while the execution efficiency went up actually as static s/w compilation is in fact producing superior command streams than what h/w SM schedulers were able to create on the fly, in process of shader execution.

This lowest SM level have nothing to do with any API as all GPUs function pretty much in the same way here in DX11, DX12, DX9, OpenGL, Vulkan, CUDA - whatever. It also can't produce any additional CPU load in process of actual execution as the command streams are being compiled for execution prior to them getting into the second "global" scheduling level. It may affect game's loading time or level loading time - but this is why NV introduced shader cache several years ago which is basically a storage of already compiled command streams meaning that even this additional CPU load is non-existing when you're launching a game for 2nd+ time.

On the actual reason of why there are some strange results on NV h/w on Ryzen in DX12 - again, B3D guys are correct in saying that this is most likely a result of NV driver suffering more from Ryzen specific architecture issues because NV's driver is a lot more multithreaded in the first place. Considering that NV spent the last 10 or so years optimizing their driver for Intel multicore CPUs it's completely reasonable to expect issues on a different multicore CPU architectures - issues, which will most likely be fixed in future driver updates.

Awesome, this is a great post! Thanks for explaining this!
 

pooptest

Member
·feist·;233255351 said:
MSI and ASRock appear to be continuing their own XMP memory compatibility improvements, apart from the updates passed on by AMD. Both ASRock's X370 Taichi and X370 Fatality Pro have received ~3-4 XMP compatibility updates since launch.

I'm waiting patiently.

I can only get these to 2667 so far:
https://www.newegg.com/Product/Product.aspx?Item=N82E16820231914

And when I set 1700X to 4.0, it won't get past the black screen. If I leave RAM at "Auto" (2133), I can do 4.0 just fine. Oyyy.

Regardless, I'm loving the build!
 

Paragon

Member
·feist·;233255351 said:
MSI and ASRock appear to be continuing their own XMP memory compatibility improvements, apart from the updates passed on by AMD. Both ASRock's X370 Taichi and X370 Fatality Pro have received ~3-4 XMP compatibility updates since launch.
For what it's worth, the Crosshair VI I was waiting on finally arrived on Sunday, after having the rest of the system sitting around all of last week, and I managed to get some of my own testing done.
Perhaps I've just been lucky, but I haven't had any difficulty running fast memory on this board when using the latest UEFI BIOS (1002).

Now I haven't done extensive stability testing yet; only a few runs of AVX2 workloads, letting AIDA64 run for 20-30 minutes, and then running games on it for several hours, but I've not experienced any instability or had any other issues with a 1700X at 4GHz using 1.35V with 3600MT/s RAM, and it's been running for a couple of days now.
The memory is Corsair's 3600C18 Vengeance LPX kit as it was the cheapest "probably B-Die" kit that I could get here. (apparently all Corsair 3600 kits are B-Die)
Even the 32x memory multiplier, which everyone has been reporting as unstable (refusing to POST) just seems to work, at the standard 1.35V.

The only issue that I have encountered so far is that it would boot with a 100MHz BCLK and the 32x multiplier for 3200MT/s, or 122.6MHz BCLK and the 29.33x multiplier for 3597MT/s, but not the 122.6MHz BCLK and the 26.66x multiplier for 3269MT/s. Which doesn't make a lot of sense.
With everything going so smoothly, it leaves me hopeful for running the four DIMM ECC kit I'm currently waiting for at 2666MT/s. Especially once the memory update is out.


That said, I've not seen much difference in games from increased memory speeds - nothing like people seem to be reporting.
Game performance has been pretty mixed though; which I suppose is to be expected at this point.

With Deus Ex: Mankind Divided, I can take it down from 8c/16t to 3c/6t and only lose a couple of FPS - though framerate consistency goes out of the window at that point.
Going from 2666MT/s to 3600MT/s only gains 4 FPS too, raising it from 57 FPS to 61 FPS in the area I normally use to test that game.
However that was in DX12. Going to DX11 raises performance from ~60 FPS to ~70 FPS, and reducing the core count in DX11 starts to greatly affect FPS.
GPU utilization still only reached a peak of 89% though - so there's 10% performance being left on the table, and that's only with a 1070. A faster GPU would be worse off.

I was really hoping that a faster CPU with a lot of cores would help Dishonored 2 more than it did, since it's based on id Tech.
Stuttering is still just as present as it was on my i5-2500K system. I guess it's just that engine.
Just like in Deus Ex, going from 2666MT/s to 3600MT/s only increased the framerate in Dishonored 2 by ~4 FPS.

It seems like it's mainly old or non-demanding games which are benefitting from the faster RAM.
I don't have Fallout 4 to test though, and that seems to be the main recent game that people report memory speed making a difference with.

I loaded up Skyrim SE as it's running on the same engine, but the game was just completely locked to 60 FPS the entire time no matter the memory speed.
It also seemed to show that the scheduler is handling things properly as that game only seemed to be running on the 8 physical cores and not the SMT cores.
Even though the main thread was hitting 95%+ load, it never dropped a frame.
I only have an early-game save in the special edition though, and have not loaded it up with mods so maybe that's not representative of how demanding the game might get.

Some games seem to absolutely love having lots of available threads, and take full advantage of the CPU though - even ones you might not expect.
ABZÛ on ultra settings absolutely destroyed my i5-2500K, and I played through that from start to finish (80 minutes) on the R7-1700X last night.
I think I noticed twice in the whole game where it ever dropped a frame - and only from 60 to 59 FPS.
Performance was really consistent here, and total CPU usage peaked at about 70%. Highest core was 77%.
I'd be really curious to see how an i7-7700K compares in this area.

After Dishonored 2 I wanted to test something else running on older id Tech 5, and The Evil Within seemed to be running very well; load spread out across all threads with my 1070 sitting at 99% utilization at all times (V-Sync off) and the game running close to 120 FPS most of the time. (at 1080p)
That's really what I was hoping to see from Dishonored 2, but whatever they did to make id Tech into the Void Engine seems to have regressed its performance.
TEW originally shipped in quite a poor state too, but the patch they released to fix that really seems to have done a good job.

I've not seen any games where it benefitted performance to limit the game to running on a single CCX.
I think there is performance to be gained if the developer optimizes their code for it, but having threads jump across CCXes doesn't seem to be an issue.
Even in games which place their load on one main core and you have a very low workload on the rest of the CPU, they always seem to perform best when given access to all the cores.

As a pure gaming CPU, it may not be the best choice right now, but it has been a very smooth experience in most games I've tested so far, even if they aren't fully utilizing the CPU.
At least when I still have a 1070, I think I may be satisfied enough with how it performs in games that I'm not going to want a separate gaming system right now.
I don't know how it will hold up with higher-end cards though, since I'm already seeing the 1070 under-utilized in some games.
 
Übermatik;232903133 said:
We have the exact same setup! Don't suppose you've gone for an ASUS DUAL RX 480 OC 8GB have you? :p

I wouldn't worry too much about the ASUS board reports - most I've seen are from people who didn't seem to be aware about Ryzen's current memory issues, which are being fixed with BIOS updates anyway.

I\m building mine tomorrow all being well, so I'll let you know how I get on!

I thought I would give you an update. After waiting anxiously for my motherboard to come in I decided to place a second order with Negegg instead since they said they had it in stock. NCIX website said the same thing but it's not. It was ready on Monday at Newegg and I ordered Saturday, great news and it appears I am not alone in trying to track one of these boards down. From what I am hearing all the X370 boards are in short supply right now. I almost tried the ASRock Taichi after hearing some great feedback about it and how good they have been with updates but I settled down when I found the Asus Prime Pro on Newegg.

To make a long story even longer I started to upgrade my current PC. Had my 16GB of Corsair 3200 memory, the 1700 Ryzen with stock cooler it came with, and my newly arrived ASUS board. It's been awhile and I made a few rookie mistakes. Forgot about the secondary power cord on the motherboard and freaked out when I flashed it up and only got a black screen. Then I didn't connect the power to one of the two fans. When installing the motherboard to the case and while cleaning up my cable mess knew I had forgotten about the Q-Shield cover for the back of the case. Unscrewed the motherboard so I could slip it in there only to find out later the wire for the fan got caught behind. Removed it again and this time really regretting not having a magnetic tipped screwdriver!

After getting it all together it was time and low and behold it flashed to the start up bios. So far so good but of course it would be too easy to just think my newly formatted SSD would just boot. Nope, another error of mine. I never used the Windows 10 boot tool. Now scambling on another computer waiting for it to download to the USB drive I waiting once again. Then in amazement it was smooth sailing after that.

My board came with the BIOS 504. They now have BIOS 515 as of March 31 but I haven't installed it. Since everything is working smoothly I might wait until they get the memory situation under control in May. My memory is defaulted to 2133 right now and the CPU is 3.3 on all cores with Windows 10 in performance mode. I want to learn more about the BIOS and tweaking before I do anything because I did alter one option (TUI?) and it got the cores running all the time to 3.3. Cinebench recorded 1330, a huge step up from my old one. Temps at idle is 36 celcius and after playing Forza Horizon 3 it reached 55 celcius. (GPU only as high as 58)

Lol, I do have the RX 480 by ASUS but it is just the stock 8GB one that first came out. I think you will be enjoying this combo because I know I am. It wasn't hugely expensive but the one thing I am upset about is my sound card won't fit on the new MB but i will save it for when I make a second PC out of my older parts. It will just be a media PC anyways.
 

eva01

Member
I am not alone in trying to track one of these boards down. From what I am hearing all the X370 boards are in short supply right now. I almost tried the ASRock Taichi after hearing some great feedback about it and how good they have been with updates but I settled down when I found the Asus Prime Pro on Newegg.

It took me 2 weeks to get an ASRock Taichi board from Newegg. The board has really great overclocking options to tinker with. I had a Gigabyte K7 and it is lacking so many options in the UEFI bios compared to the Taichi. Newegg had the ASRock x370 Fatality Gaming in stock a few hours ago but its out of stock again. You will need to keep checking every hour. The board is definitely worth it. Both the Gigabyte K7 and ASRock Taichi gave me zero problems with my RAM. The Taichi was able to give my 1700x a 50MHz higher stable overclock(4GHz) over the Gigabyte K7(3.95GHz).
 
It took me 2 weeks to get an ASRock Taichi board from Newegg. The board has really great overclocking options to tinker with. I had a Gigabyte K7 and it is lacking so many options in the UEFI bios compared to the Taichi. Newegg had the ASRock x370 Fatality Gaming in stock a few hours ago but its out of stock again. You will need to keep checking every hour. The board is definitely worth it. Both the Gigabyte K7 and ASRock Taichi gave me zero problems with my RAM. The Taichi was able to give my 1700x a 50MHz higher stable overclock(4GHz) over the Gigabyte K7(3.95GHz).

I will just settle with my ASUS board, it is about 2/3 the price and is running fine now aside from my memory locked at 2133 but i haven't even tried to update to a new BIOS yet. ASRock is definitely giving out BIOS updates at a faster rate than anyone else.
 
This was posted on Reddit earlier but overclockers.ru ran some power consumption figures of Ryzen 7 at 100% load:


This bodes well for any future consoles, as a 2.8-3.0 GHz 8c16t part in a 35-45W TDP would be quite feasible.
 
This was posted on Reddit earlier but overclockers.ru ran some power consumption figures of Ryzen 7 at 100% load:



This bodes well for any future consoles, as a 2.8-3.0 GHz 8c16t part in a 35-45W TDP would be quite feasible.

I was also thinking the same thing, a 2.5-3GHz 6 core 12 thread or 8 core 16 thread Zen-based CPU would be incredibly feasible for a console, and would perform exceptionally well.

EDIT: Even a 6 or 8 core without SMT would perform exceptionally well.
 

Papacheeks

Banned
This appears to be one of the first reviews of the Ryzen 5 1600, it looks awesome!

First full review of AMD Ryzen 5 1600 is here



I'm familiar with some of the things mentioned early in the video as I've researched them before so I was surprised to see someone explaining them to people, but some of the things later are questionable, could you please elaborate on where else he was wrong?

Yea, that review is shit. They compare the x1600 to teh i7 7700k running at 4.9-5.0ghz and have the intel running DDR4 3600. But yet only have 2400ghz ram for the x1600?

And there are a couple of boards who have the BIOS updates for xmp profiles and support for 3200.
 

SRG01

Member
More on nVidia's driver overhead: rendering performance using CUDA/Iray, even with GPU only, is critically dependent on CPU performance as nVidia's current implementation requires the CPU to perform certain tasks. There's actually a bottleneck that occurs with multi-GPU rendering -- not SLI, mind you -- because lower-end CPUs cannot keep up.

There are massive threads on it online on other forums and is widely known at this point.
 

spyshagg

Should not be allowed to breed
I already purchased two ryzens for my company. At this price point, there really is no going back to intel.
 

dr_rus

Member
https://twitter.com/FioraAeterna/status/847472836344033280
https://twitter.com/FioraAeterna/status/847835875127959554

Dunno if posted already but these basically confirm that all gains in AotS Ryzen patch were due to improvements in memory management - i.e. working around the cross CCX latency issues.


More on nVidia's driver overhead: rendering performance using CUDA/Iray, even with GPU only, is critically dependent on CPU performance as nVidia's current implementation requires the CPU to perform certain tasks. There's actually a bottleneck that occurs with multi-GPU rendering -- not SLI, mind you -- because lower-end CPUs cannot keep up.

There are massive threads on it online on other forums and is widely known at this point.

Read my post above. Rendering does not "critically depend on CPU" on NV's h/w.
 
Been busy dealing with what appears to be a dead PC. Another system, my Intel Xeon, which is stuck on an odd boot-loop that's not quite a boot loop, but either way it's not functional.

Also a third system, my Ryzen, which seems to have suffered a dead water cooling pump issue so I have to work on whether anything else may have been effected and now needs to be replaced. Great..


dr_rus,
On a cursory look your Nvidia post doesn't seem to indicate your original stance of the person in that video having zero idea of what he's discussing throughout. There does certainly seem to be some key issues and it's curious that I could also be mistaken or misinformed on similar to the presenter (don't know who he is so he wasn't a source of info for me).

More importantly, I have no qualms about being corrected whenever I may be wrong as we are all here as enthusiasts learning. l welcome the check no matter how embarrassing it may be. *ominous foreshadowing* The last thing I would want to do is propagate misinformation or spread opinion as fact.

Assuming I can edit w/o issue from this device, I'll be removing that GPU driver video I had added as a reference from the OP, at least until I can look into this further myself.


As mentioned, everyone's contributions from links to first hand experiences are appreciated as they add to a greater perspective and understanding. Now back to those 3 PCs...
 

tuxfool

Banned
MOVNTs not causing chip wide flushes seems like a solid optimization of cross CCX communication events.

I'd question whether it is an optimization if other game developers are not using it (we don't really know). Given that not using them seemingly has no impact on Intel architectures, I'd have to question why they chose to use them in the first place.

Or maybe they didn't, it seems like the MOVNT's were a bug that disappeared when they moved from MSVC 2015 to 2017.
 

Datschge

Member
The related AMD Ryzen™ Community Update #3
  • The AMD Ryzen™ Balanced power plan still permits aggressive power management. There should be little difference between the OEM Balanced and the Ryzen Balanced plan. We’re interested in your feedback!
  • Performance of the AMD Ryzen™ Balanced power plan should be on part with the High Performance plan. We're interested in your feedback on this, too.
  • Finally, if you see a third-party tool reporting “idle” clocks in the range of 3200-3400MHz, you can be virtually certain that the core is actually sleeping and the tool is simply reporting the last known P-State.
The new AMD Ryzen Balanced power plan installer download.

Ryzen Master was updated as well:
  • Ryzen Master now reports junction temperature, rather than tCTL, by automatically removing the tCTL offset on the AMD Ryzen 1800X, 1700X, and 1600X processors.
  • The installer no longer enables or requires HPET when Ryzen Master is installed with a system running an AGESA 1.0.0.4-based BIOS.
 
Got my Asrock X370 Gaming K4 in the mail today. Holy hell, this box is huge and weighty. The mobo box is just slightly smaller than the box they shipped it in.

All I need now are my Cryorig H7's AM4 bracket and an R5 1600X.
 

Paragon

Member
The launch seemed to be very rushed for some reason.
The good thing is that they are at least continuing to work on things and are rapidly pushing out updates.
I had been running at a fixed overclock for a while now, and with this new power plan I can use p-state overclocking so that it boosts to the same speed but idles much lower without parking the cores, so I'm pretty happy with that.
 
Legit Reviews —— AMD Ryzen Balanced Power Plan Benchmarked


HardOCP TV [YouTube] —— AMD Ryzen 5 1600 and 1400 Overclocking Results



looks like Linus Tech Tips did a video on exactly what I've been wondering about regarding streaming.

https://www.youtube.com/watch?v=jludqTnPpnU
Glad you were able to get a decent Intel QuickSync vs Ryzen comparison. As you know there haven't been many.

Nice to see they included software results against the 6900K and 7700K, along with the other tests.
 
Wow, I saw a Ryzen 5 1600 for £220. Beautiful, this is truly amazing! A 6 core 12 thread processor for this price is simply one of the greatest value products of all time!
 
Top Bottom