AMD is sending Ryzen/Radeon care packages to game developers | Hacker News Reader

AMD is sending Ryzen/Radeon care packages to game developers

overclock3d.net

132 pointsvaleg51 comments

Open articleView on HN

Does anyone @ AMD want to help out our niche developer/gaming community? ;-)

https://www.reddit.com/r/openbsd_gaming/

edit: With OpenBSD developer hat on, hardware donations welcome here too: https://www.openbsd.org/want.html

Especially if it helps out er... "gaming" in OpenBSD hosted VM's on AMD cpu's. ;)

I can also think of many Wayland developers and Linux graphics people who could use the hardware.

I don't think I've seen any AMD employees on HN. I wonder if there's a better contact.

I've seen AMD representatives on Reddit's r/amd often. Maybe parent poster can try there.

Thanks! You never know.

https://www.reddit.com/r/Amd/comments/8u8c80/amd_is_sending_...

There are quite a few who frequent the Phoronix forums as well.

> 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.

https://community.amd.com/community/gaming/blog/2017/06/23/e...

I don't know actual details of that, but words on the internet said that it is just a bug fixed.

> it is just a bug fixed.

As such, we programmers find GREAT interest in these sorts of bug fixes. Every bug is an opportunity for a programmer to learn more about computers!

> Every bug is an opportunity for a programmer to learn more about computers!

Most bugs I've fixed have taught me relatively little about computers but lots about myself.

https://developer.blender.org/T53068

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.

I'd love to learn more about Windows pthreads poor implementation of spinlocks mutexes. Do you have any cool links?

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.

Third: my analysis is derived from the Blender diff here: https://dev-files.blender.org/file/data/rjmzozouj44bs6qicd3y...

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.

https://docs.microsoft.com/en-us/windows/desktop/Sync/critic...

Critical sections are Windows's lightweight yielding / task sleeping mechanism.

---------

Finally, Windows provides a spinlock: https://docs.microsoft.com/en-us/windows/desktop/api/synchap...

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:

https://news.ycombinator.com/item?id=17336853

These days it would likely be best to implement pthread-win32 mutexes using WaitOnAddress.

Huh, I didn't know about this new primitive. Thanks! It seems to have been introduced into Windows 8 and later, as a competitor against Linux's futex.

I did a brief search online, and Raymond Chen had this to say:

https://blogs.msdn.microsoft.com/oldnewthing/20160825-00/?p=...

> [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.

Ah yes, I forgot about condition variables. That makes sense then.

AMD send out hardware all the time.

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.)

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:

https://www.reddit.com/r/Amd/comments/5x7oaq/ryzens_memory_l...

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].

[1] http://3dfmaps.com/CPU/cpu.htm

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.

Vulkan translation is important for more demanding engines. UWP doesn't seem to support Vulkan even on Windows: https://github.com/KhronosGroup/Vulkan-Docs/issues/366

On Xbox there is no option but to translate to D3D12 anyway.

More demanding games are doing just fine with Cocos2d-X, Unreal, Unity, Ogre3D, Crytech, Lumberyard....

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.

A little off-topic, but planning on building a Ryzen 2600x system soon. Does anyone know if Ubuntu works well with Ryzen processors?

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 was using a 1600X and it worked fine. Using a 1950X and still works fine. I pretty frequently put it under heavy load.

It will be fine. I'm running Mint and Kali on some slightly older Ryzens for a year now without issue.

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.

The problem that was causing a lot of the lockups was errata #1109 "MWAIT Instruction May Hang a Thread"

See https://developer.amd.com/wp-content/resources/55449_1.12.pd...

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.

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.

Do you mean Ryzen 2200G and 2400G with APU?

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.

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.

Yeah, In retrospect I should have done my research on this front. Mea culpa.

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.

If you end up getting a motherboard without a compatible BIOS, AMD will send you a temporary CPU for free. (https://support.amd.com/en-us/kb-articles/Pages/2Gen-Ryzen-A...)

Yes, but if you use this program you have to get a RMA from your motherboard manufacturer first stating they wont do anything to help.

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.

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.

1. https://bugzilla.kernel.org/show_bug.cgi?id=196683

2. https://developer.amd.com/wp-content/resources/55449_1.12.pd...

I'm running Ubuntu 18.04 in VirtualBox on a Ryzen 1700 and haven't encountered any issues.

I run Debian (proxmox) on a Ryzen 5 2600. Works well!

On the same note, how about Ryzen laptops? Are there any in the market that work well with linux?

Wake me up when they start hiring driver developers.

Reply on news.ycombinator.com