Tag Archives: AMD

AMD EPYC 7343 / EPYC 7443 Linux Performance Review


Since the AMD EPYC 7003 “Milan” series launch back in March we have carried out many benchmarks with their flagship processors like the EPYC 7763 and 7713 processors and some of the frequency optimized SKUs, but what about the performance lower down the product stack? Up for benchmarking today is a look at the AMD EPYC 7343 and 7743 processors in 1P and 2P configurations against other AMD EPYC Milan processors as well as Intel’s Xeon Platinum 8380 Ice Lake processors.

The AMD EPYC 7343 is a 16-core processor with SMT for 32 threads. This 190 Watt server processor has a 3.2GHz base clock frequency and can boost up to 3.9GHz while having a 128MB L3 cache.

The AMD EPYC 7443 meanwhile is a step higher with 24 cores / 48 threads while the base frequency drops to 2.85GHz but a boost clock up to 4.0GHz. The EPYC 7443 has a 200 Watt TDP and 128MB of L3 cache.

As is standard for AMD’s straight-forward EPYC processor line-up, all of these EPYC 7003 series processors support eight channels of DDR4-3200, 128 lanes of PCI Express 4.0, Secure Encrypted Virtualization (SEV), and other features in common throughout all their SKUs. The EPYC 7343 carries a 1Ku price of around $1565 USD while the EPYC 7443 is at around $2010.

The AMD EPYC 7343 and 7443 in both 1P and 2P configurations were benchmarked up against the EPYC 7713 and EPYC 7763 processors using the same Daytona reference server. The performance was also compared to the Xeon Platinum 8380 given those are the only Ice Lake processors we have our hands on at the moment. I’ll be back around with more comparison benchmarks when getting my hands on additional SKUs.

All CPUs tested were with each configuration at its maximum rated channels and frequency supported. using a Intel NVMe D7-P5510 7.68TB enterprise SSD, and for this go around of benchmarking using Ubuntu 21.04 with the Linux 5.13 kernel for providing a very bleeding-edge look at the performance.

For this benchmarking bout, 115 tests were carried out across all the processors under test. Given the number of benchmarks being run, first up is looking at the performance at a higher level across a few key areas before diving into some of the most interesting individual benchmarks. At the end of the article is a link to the OpenBenchmarking.org result file for seeing all 115 benchmark results in full as well as being able to generate your own performance-per-dollar complementary graphs based on local/available pricing, etc. Thanks to AMD and Intel for supplying the CPUs under test for this review.


AMD Has Yellow Carp Ready For Linux 5.14, More Smart Shift Updates + Display Fixes


RADEON --

Along with Intel having wrapped up their graphics driver feature work for Linux 5.14, AMD sent in another pull request too with more feature code they have ready for their AMDGPU kernel driver in 5.14 and will likely be their last major pull for this cycle too.

The AMD Radeon kernel graphics driver code for Linux 5.14 has already seen a number of features and improvements queue in DRM-Next. The exciting bits so far for Linux 5.14 on the red side include more Aldebaran accelerator bring-up work, HMM SVM support, PCI Express ASPM being enabled by default for relevant GPUs, TMZ support for Renoir, Van Gogh APU updates, Beige Goby support, GPU hot unplug support, AMD Smart Shift support for laptops, 16 bpc support for use by their Vulkan drivers, and a lot of smaller changes.

Within today’s potentially final feature pull request, AMDGPU has ready Yellow Carp as the newest RDNA2 GPU. AMD published their initial Yellow Carp hardware enablement driver code earlier this month and it’s ready to be introduced in Linux 5.14 in continuing the recent trend of providing launch day open-source AMD GPU support in the mainline kernel.


AMD’s Linux catered codenames for volleying early hardware bring-up for their GPUs continue to involve an X11 color followed by a fish species.

Besides having Yellow Carp support, there are SR-IOV fixes, updates to the new Smart Shift support, GPUVM TLB flushing changes, cleanups for BACO (Bus Active, Chip Off), various DC display code fixes and improvements, and a variety of other internal code clean-ups/changes.

The full list of AMDGPU changes heading to Linux 5.14 with this pull by way of DRM-Next can be found with this pull request.


AMD Is Hiring More Linux Engineers For The Scheduler, Memory Management, Net I/O


AMD --

It looks like AMD’s rising marketshare in the data center is paying off as AMD is hiring more Linux kernel engineers.

On top of hiring more Linux engineers earlier this year as part of a client-focused push, it’s been brought to my attention they are now looking to hire several more Linux kernel engineers. This time around they appear to be focused on Linux kernel work in the server / EPYC space but some of that work does also carry over to benefit AMD desktop/mobile efforts as well.

AMD’s latest round of job postings pertaining to Linux are based out of a mix of Austin, Texas and Bangalore, India. Among their many Linux job openings at the moment:

Linux Kernel – Scheduler Development Lead – Great to see AMD working on kernel scheduler improvements with an emphasis on performance. Hopefully this will also carry over to CPUFreq / CPPC with Schedutil and related work there. There is apparently a “small scheduler focused team” building up by AMD in India with a focus on optimizations/features for EPYC.

Linux Kernel – Memory Management Development/Performance Lead – Again, great seeing AMD working more on low-level Linux kernel infrastructure and more performance optimizations.

Networking I/O Lead – In Austin, it’s great to see AMD hiring for multiple networking I/O related Linux positions to focus on performance and low-latency I/O and scalability.

Linux Virtualization Performance Lead – One of several positions around Linux virtualization for EPYC with a focus on KVM/QEMU.

See more of AMD’s open Linux-related positions via jobs.amd.com.

While they have worked to ensure sufficient launch-day Linux support across their product portfolio, they have rather neglected any core infrastructure improvements for Linux the past number of years since they shutdown the OSRC. So it’s great to see them seemingly getting more talent to work on upstream core kernel improvements beyond just new product enablement and working to tune their hardware for optimal performance/functionality on Linux. This is one of the areas where Intel has long held an advantage over other vendors is with their vast teams of experienced open-source/Linux engineers working not only on hardware bring-up but also improving the Linux kernel and related components around power management, scheduler enhancements, and more along with ensuring other key software is well tuned for their hardware.


AMD Continues Working On SmartShift Support For Linux


AMD --

Announced last year by AMD was SmartShift Technology for laptops with both AMD CPUs and GPUs to allow dynamically shifting the power budget between the CPU/GPU depending upon the current workload. AMD promoted SmartShift as delivering up to 14% extra performance and now this technology is being worked on for their Linux driver.

AMD describes SmartShift as “AMD SmartShift enabled notebooks feature a hardware boosting interface between the Processor and Graphics with machine learning algorithms to automatically boost performance where workloads demand it. This interface links the common Infinity Control Fabric blocks together so that the CPU and GPU react quickly to different workloads.

SmartShift appeared in select all-AMD notebooks last year before saying the roll-out was paused until 2021. At Computex Taipei 2021 they talked again about SmartShift briefly and we are also seeing the latest Linux kernel patches posted for enabling SmartShift on Linux.


AMD this week for Computex Taipei began re-talking about SmartShift after announcing it last year. (Coincidentally?) new Linux patches have also been appearing.

Published on Sunday was the fifth time a patch for AMDGPU was submitted for enabling SmartShift with the discrete Radeon notebook GPU when part of a supported system.

Today was also another patch sent out again for exposing the SmartShift power-share information to user-space via sysfs. This exposes the APU and dGPU power sharing information to user-space for monitoring the behavior and verify that it is in fact working on a given system. The sysfs information will indicate how much of the APU power headroom is being used by the discrete GPU.

A follow-up patch adds a writable sysfs attribute for controlling the SmartShift bias level. From -100 to 100 is the interface for setting -100 to prefer maximum APU performance while 100 is for preferring maximum GPU performance with the default 0 level being balanced performance.

So it seems the SmartShift support for Linux is getting squared away in time for the next round of AMD Ryzen + Radeon laptops coming to market. Presumably this time around there will be more prevalent SmartShift support given their newly-announced AMD Advantage program and more time to bake the SmartShift functionality since last year’s initial debut.

These SmartShift Linux patches haven’t yet been queued into any development trees but if deemed ready soon enough could still make it for the 5.14 kernel otherwise postponed to later in the year.


Experimental RADV Code Allows Vulkan Ray-Tracing On Older AMD GPUs


RADEON --

AMD currently just supports Vulkan ray-tracing with their Radeon RX 6000 series graphics cards while now there is independent work being done on Mesa’s unofficial Radeon Vulkan driver (RADV) to allow ray-tracing to work with older generations of GPUs like Vega and Polaris.

Joshua Ashton who is known for his work on VKD3D-Proton, DXVK/D9VK, and related projects while working under contract for Valve has been experimenting with bringing RADV Vulkan ray-tracing to pre-RDNA2 GPUs.

While RDNA2 GPUs offer hardware acceleration around BVH ray intersection tests, there isn’t much more that is actually new silicon for ray-tracing with these latest consumer GPUs. But the ray intersection tests can also be handled as a SPIR-V shader for any GPU as well, so that is what Ashton has been experimenting with.

With a lot of work, he does have some RADV experimental code working that besides using the branched code also requires some environment variables be set (RADV_PERFTEST=rt RADV_DEBUG=nocache). He has some very basic Vulkan ray-tracing demos now rendering for Polaris/Vega graphics processors.

RADV in general still needs more Vulkan ray-tracing wokr before it can handle more advanced Vulkan RT demos or games like Quake II RTX. There is also the in-progress VKD3D-Proton support for DirectX Ray-Tracing over Vulkan Ray-Tracing, which will be another target to experiment with in time.

So there’s more work ahead before this RADV code would really be usable or ready for mainlining to entertain Linux gamers on older graphics cards. It also remains to be seen how this shader-based implementation will perform if it will even be good enough for handling any ray-traced games.

In any case, see Joshua’s blog for more details on this ongoing effort for Vulkan ray-tracing on older generations of AMD GPUs.