> Several professional tools were also updated, with Zbrush offering a 204,772% performance improvement in specific workloads, showcasing how much can be gained when software is optimised with Ryzen in mind.
Comments indicate that's not a misprint. I'd love to hear the details of a 204 thousand percent improvement.
So I dunno about ZBrush. But Blender is a similar 3d program. There was a multithreading issue which would cause Blender to work for HOURS before actually completing some trivial tests.
Clearly, AMD Zen / Infinity Fabric has an edge case that older systems can handle just fine. Note that Blender uses Windows pthreads, which has an incredibly BAD implementation of spinlocks and mutexes.
Blender fixed this issue by making a customized implementation of spinlocks. I dunno what ZBrush did, but these kinds of architectural regressions happen every now and then.
Citation: myself. I'm not an expert but I think I know enough to see a bad implementation when I see one. As such, please take this analysis with a grain of salt.
Second: I'm not entirely sure if this applies to "modern" pthreads-win32, but the Blender project uses a relatively old build of pthreads-win32.
I'm assuming that the Blender devs are smarter than me and have already tested this. :-)
------------
So going through the Blender source code we come across pthread_spin_lock as part of the diff. Considering the comment thread (as well as the diff) as adding Win32 #ifdefs and such, we can assume this was the cause of the performance issue.
---------
I assume... okay, so my logic isn't 100% tight, sorry :-(... that the implementation uses this pthreads-win32: http://sourceware.org/pthreads-win32/
Which brings us to here: ftp://sourceware.org/pub/pthreads-win32/sources/pthreads-w32-2-9-1-release/pthread_spin_lock.c
---------
Lets break it down why this is a bad implementation:
1. No "pause" instruction, causing latency issues when leaving the spinlock. See https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... or https://software.intel.com/en-us/node/524249 for more information on why "pause" should be used in every spinlock. Strangely enough, the "pause" instruction is found in Linux implementations of pthreads (so the author for pthreads-w32 just... didn't look at the Linux implementation or something?)
2. PTW32_INTERLOCKED_COMPARE_EXCHANGE_LONG seems inefficient to me. I'd imagine that the usage should be using a swap instead (aka: https://docs.microsoft.com/en-us/windows-hardware/drivers/dd... ). Although I don't have any microbenchmark that "proves" this, I'd imagine that a swap is more efficient than a compare-and-swap.
3. A potential "slowpath" which includes a mutex-lock. Note that Windows Mutexes are incredibly heavy: including security features and even a "filesystem like" naming scheme. (See Windows Object Handles if you don't believe me). Windows Mutexes are very fully featured: recursive, multiple levels of security, and more.
This is a common problem in Linux system-coders -> Windows system coders. The Windows "Critical Section" is a more appropriate replacement for Linux pthread_mutexes.
I'd say Windows Mutexes might be more similar to a Linux filesystem-level semaphore. Linux semaphores provide those security features integrated with the filesystem.
The to Linux mutexes and spinlocks is something called a "Critical Section" in Windows land.
Which is probably is what pthreads-w32 should really be using. I mean, Linux devs basically just don't know what Windows offers, and the pthread-win32 library is a poor fit at the moment.
-----------------
Sorry if you were expecting more complete analysis and testing. Lol. Its mostly me looking at the thing and making a guess and reverse-engineering the patch-notes from the Blender discussion.
Tangentially relevant: Microsoft .NET was 50% slower on Skylake (some loads) due to changes by Intel to the pause instruction interfering with poor spinlock implementation by Microsoft:
> [snip] in real life, you should just use EnterCriticalSection because it has stuff like spin counts and lock convoy resistance.
Is there anything that pthread_mutex_lock does that EnterCriticalSection doesn't do? It seems like a good "translation" to me. I'd only use the WaitOnAddress thing if pthread_mutex_lock had some features that a raw EnterCriticalSection wouldn't do.
You need to be able to link your pthread condition variable implementation to your pthread mutex implementation such that a pthread_cond_wait() does an atomic wait-on-condition-variable-and-unlock-mutex, noting that another thread can signal the condition variable without holding any mutex.
In addition, pthread mutexes can be statically initialised which requires some kind of initialise-on-first-use for those if you implement them using Critical Section objects.
I believe WaitOnAddress(), rather than being a "competitor" for futex was actually added (or at least, the underlying infrastructure was) in order to be able to implement futex() in the WSL.
Since ZBrush is a widely used 3D program, it may come as a surprise to many that it barely uses the GPU, relying almost exclusively on the CPU to render millions-of-polygon models at interactive speeds. ( https://pixologic.com/zbrush/system/ ) So there are big performance benefits to tuning ZBrush to take advantage of a particular processor's features and avoid its weaknesses.
I'm also curious what the exact issue was, but given the scale of improvement, I wouldn't be surprised if it is some sort of cache contention between threads/processors. A cache miss in the inner loop of an algorithm can be catastrophic, and apparently Ryzen has pretty different cache behavior versus other CPUs:
When I worked at a visual effect software house, AMD would send us all sorts of things. The main problem was thier linux drivers were terrible.
A lot of the time thier hardware was faster at certain things. At one point (this is about the time of the quadro 2/3/4/5/6/000) the AMD firepro was 8 times as fast. However their driver support was terrible, and the time to fix was 6months+
There was a reason why the mac pro had two AMD GPUs in them, they were at the time light years faster.(and cheaper.)
According to the comments it was a 22 second workload reduced to 11 milliseconds. If that's true, it's mind-numbingly insane. That's an order of magnitude improvement over going from a 80386 to a modern Core i7 (~14,000%)[1].
Will such optimizations help in Wine on Linux too?
> Game developers also know that next-generation consoles from both Sony and Microsoft are on the horizon, both of which are likely to use Ryzen/Radeon CPU and graphics hardware, making now the perfect time to start looking deeper into Ryzen. Both future consoles are also expected to feature Radeon graphics features like Rapid Packed Math, which enables FP16 calculations to be completed 2x faster than standard 32-bit math, allowing some graphical elements to be accelerated, assuming the extra precision of FP32 isn't required.
Is anyone working on unblocking Sony's PlayStation lock-in, to provide Vulkan → GNM translation layer? There is such effort for D3D12 which will address Xbox.
fwiw, SDL2-based games that use regular OpenGL are already portable to XBox because SDL2 has a UWP backend and you can run ANGLE on UWP to get OpenGL support. There's even a working implementation of FNA for it which means old XBox Live Indie Games titles can be ported over easily.
I love this. I recall when Palm did an SF event and I thought they should have given every participant a phone–they didn't. Not long after they were gone.
Does anyone have any good info on Ryzen ECC RAM support? I’ve read a bunch of conflicting information and that some motherboard vendors have been misleading.
It’s very straightforward: ECC is fully supported by the CPU and chipset, but must be accounted for by the motherboard maker. Check the specs/manual for the motherboard before buying, in particular the tested hardware list.
I’ve been using 32GB of ECC DDR4 with a 1950X and X399 Taichi without a problem.
I've also been using ECC with a 1950x, but an X399 Asrock Pro-gaming board. I've confirmed that it works by watching errors when overclocking the memory.
FYI, the problem you might read about with lockups when using Ryzen and Linux are related to old power supplies that don't handle the low power settings well. As long as you have a fairly new power supply you shouldn't have any issues. At least this is the conclusion I drew after doing some research before building a 1600 based system a while back.
Just switched my home desktop to a Ryzen 2600X / Gigabyte AX370M-DS3H motherboard: Only hiccup was having to source a pre-ryzen AM4 cpu to update to BIOS to get Ryzen support, which was a pain - I'd advise making sure that any board you buy has had the BIOS updated if required by the seller.
I run Debian Testing mostly, so a 4.16.16 kernel. Been perfectly stable for me so far.
NB - For anyone hoping to use the the new AMD Vega CPUs with integrated graphics, the Debian kernels don't have the relevant support compiled in, so you'll have to compile a custom kernel & grab the latest firmware files from the linux-firmware git repo if you want accelerated graphics.
Yes, but online reports suggest the round trip time is a couple of weeks. I ended up ordering the cheapest possible AM4 CPU from Amazon Warehouse & returning it after updating the BIOS instead.
A tech forum that's local to me ran a 'CPU forwarding ring' - you could sign up to have a CPU sent to you, and after upgrading your BIOS you'd have to send it to the next person who needed it. I thought that was a genius solution.
That was why I was thinking of going with a X470 mobo, though they are more expensive than the B350 and B370 boards. Id go with the cheaper but it seems that even those advertised as being upgraded to the 2000 have reviews claiming otherwise, so its kind of a mess.
Yes - I built a pair of machines - one mini ITX B350 motherboard with a 2400G CPU/GPU & the second an X370 board with a Ryzen 2600 that used a GPU I already owned.[1]
The first came with an updated BIOS & the 2400G worked out of the box. The second came with it's original BIOS. Both were ordered from Amazon. If you order from a smaller outfit they’ll hopefully be able to tell you whether the motherboard box has the sticker on it that says that its BIOS has been updated to cope with Ryzen CPUs.
[1] Still hoping for the great crypto-currency crash in the sky to bring down GPU prices. In the meantime the 2400G is adequate for console grade gaming on the TV.
I bought an ASRock B350 a couple of days after the Ryzen 2400G release. It was flashed with a firmware new enough to handle it. The Gigabytes waited a LONG time to bring their boards up.
Yes, no matter what you get chances are it'll work well. I currently have a 1700X with an Asrock X370 Fatality Mini itx board and it works perfectly. I recommend checking out level1techs on youtube as they test motherboards with linux in mind.
I'm running Ubuntu 18.04 on Ryzen 2400g with 4.17rc kernel with no issues. In stock 4.15 I'm having some issues with vega(g) part of CPU. X shouldn't have this problem.
I'm using Ryzen 2700X with Debian testing just fine. That lock-up bug[1][2] was common in previous line (1700X for instance). It's way less common in Ryzen 2.
https://www.reddit.com/r/openbsd_gaming/
edit: With OpenBSD developer hat on, hardware donations welcome here too: https://www.openbsd.org/want.html