Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Linux 4.20 Showing Some Performance Slowdowns

Filed under
Graphics/Benchmarks
Linux

Being well past the Linux 4.20 merge window I have moved onto benchmarking more of this development version of the Linux kernel. Unfortunately, there are some clear performance regressions.

This week I got to firing off some Linux 4.20 kernel benchmarks... I started with the AMD Ryzen Threadripper 2990WX and Intel Core i9 7980XE for being the interesting HEDT CPUs in my possession at the moment. On the 7980XE I spotted several performance regressions with this Linux 4.20 development kernel compared to Linux 4.19 and 4.18, so then I fired up the completely separate Intel Core i9 7960X box to carry out the same tests. Sure enough, with that different hardware, there is further confirmation of slowdowns with Linux 4.20.

The common trait of these systems was Ubuntu 18.10 x86_64 and using the Linux 4.18.18, 4.19.1, and 4.20 Git kernel packages provided by the Ubuntu Mainline Kernel PPA. With the differing hardware the intention is not to compare the performance between the systems but in looking at the direction of the Linux kernel performance.

Read more

Benchmarking Packet.com's Bare Metal Intel Xeon / AMD EPYC Cloud

Filed under
Graphics/Benchmarks

With the tests earlier this week of the 16-way AMD EPYC cloud comparison the real standout of those tests across Amazon EC2, Packet, and SkySilk was Packet's bare metal cloud. For just $1.00 USD per hour it's possible to have bare metal access to an AMD EPYC 7401P 24-core / 48-thread server that offers incredible value compared to the other public cloud options for on-demand pricing. That led me to running some more benchmarks of Packet.com's other bare metal cloud options to see how the Intel Xeon and AMD EPYC options compare.

Packet's on-demand server options for their "bare metal cloud" offerings range from an Intel Atom C2550 quad-core server with 8GB of RAM at just 7 cents per hour up to a dual Xeon Gold 6120 server with 28 cores at two dollars per hour with 384GB of RAM and 3.2TB of NVMe storage. There are also higher-end instances including NVIDIA GPUs but those are on a dynamic spot pricing basis.

Read more

The Newest Mesa NIR/SPIR-V Code For Handling OpenCL Kernels

Filed under
Graphics/Benchmarks

It's now been nearly one year since longtime Nouveau contributor Karol Herbst joined Red Hat where one of his big projects has been working on OpenCL support for this open-source NVIDIA driver by bringing up NIR/SPIR-V support and making the necessary improvements for allowing OpenCL kernels to be represented in that IR commonly used by the Mesa drivers. The work still isn't yet in Mesa Git, but Karol this week sent out his newest patches.

Karol Herbst sent out 22 patches this week in regards to adding support for OpenCL kernels within Mesa's NIR and SPIR-V common code. The patches are mostly adding the necessary OpenCL bits to the common NIR/SPIR-V compiler code for handling the intricacies of OpenCL kernels with features like physical pointer support, cl_size/cl_alignment, and other bits.

Read more

Trying DragonFlyBSD & FreeBSD On The Intel Core i9 9900K With ASUS PRIME Z390-A

Filed under
Graphics/Benchmarks

Since last month's Intel Core i9 9900K launch for this eight core / sixteen thread processor we have explored its performance for Linux gaming, how the performance and power efficiency go from the Intel 990X to 9900K, the Spectre mitigation costs, and the Intel Coffeelake Refresh performance across various Linux distributions. For those curious about using the new Intel CPUs and Z390 motherboards with one of the BSD operating systems, I spent a few days over the weekend trying out FreeBSD and DragonFlyBSD releases with the i9-9900K and ASUS PRIME Z390-A motherboard combination.

Read more

Graphics: Screen Tearing, Wayland Alpha Compositing Protocol, AMDGPU

Filed under
Graphics/Benchmarks
  • What Is Screen Tearing and How to Get Rid of It on Linux

    Unfortunately for Linux fans, screen tearing is, and has been, a persistent annoyance that doesn’t seem to be going anywhere. There are a couple of factors enabling the longevity of the screen tearing issue.

    First, and probably most obviously, is the dated, broken, and bloated X server. Even with the progress of Wayland, X is here to stay for the immediate future. Next is the strange and inconsistent graphics driver picture. One of the biggest offenders in causing screen tearing is also the most popular GPU manufacturer on Linux, NVIDIA. Throw in different desktop environments with their own display settings and compositors, and you have a real mess.

    These methods will hopefully eliminate screen tearing in most situations, but it’s impossible to provide a one-size-fits-all solution, thanks to the amount of variables involved. Try what applies to your system, and keep in mind that there might be new factors involved.

  • Collabora Revives Work On Alpha Compositing Protocol For Wayland

    Collabora's Scott Anderson has revived work on the alpha compositing protocol for Wayland, which is based upon the work done by Google on this functionality for Chromium on Wayland.

    The Wayland Alpha Compositing Protocol is intended to control the alpha compositing and blending of surface contents within a Wayland environment. This experimental protocol allows for advanced blending and alpha operations on Wayland surfaces (wl_surface) and Google's work on it dates back at least two years.

  • Radeon Linux Driver Preparing Adaptive Backlight Management (ABM)

    The "AMDGPU" Radeon Linux kernel graphics driver is preparing support for "Adaptive Backlight Management" as a backlight power-savings feature for laptops.

    Adaptive Backlight Management reduces the backlight level in an effort to save power but increases the pixel contrast and luminance to improve image quality and readability under the lower light condition.

A Look At The GCC 9 Performance On Intel Skylake Against GCC 8, LLVM Clang 7/8

Filed under
Graphics/Benchmarks

With GCC 9 embarking upon its third stage of development where the focus ships to working on bug/regression fixes in preparation for releasing the GCC 9.1 stable compiler likely around the end of Q1'2019, here is a fresh look at the GCC 9 performance with its latest development code as of this week compared to GCC 8.2.0 stable while using an Intel Core i9 7980XE test system running Ubuntu Linux. For good measure are also fresh results from LLVM Clang 7.0 stable as well as LLVM Clang 8.0 SVN for the latest development state of that competing C/C++ open-source compiler.

Read more

Graphics: Vulkan, Wayland, AMD, Mesa and Vulkan

Filed under
Graphics/Benchmarks
  • Vulkan 1.1.92 Released, Finally Allows For Chunked HTML Documentation

    Vulkan 1.1.92 is out today to mark the newest specification update to this high-performance graphics/compute API.

    With it just being one week since Vulkan 1.1.91 that brought some new/improved extensions, there isn't any new extensions to find with Vulkan 1.1.92. But there are a number of documentation/specification corrections and clarifications.

  • Wayland Protocols 1.17 Brings Explicit Synchronization & Primary Selection

    Jonas Ådahl of Red Hat today released a new version of Wayland-Protocols, the collection of stable and unstable protocols for extending Wayland functionality.

    With the Wayland-Protocols 1.17 release the big new feature is the initial (unstable) version of linux-explicit-synchronization. The Wayland explicit synchronization protocol provides a means of explicit per-surface buffer synchronization. This synchronization protocol is based on Google Chromium's extension (zcr_linux_explicit_synchronization_v1) and lets clients request this explicit synchronization on a per-surface basis. Google, Intel, and Collabora were involved in the formation of this extension.

  • The Radeon GCN Backend Is Still Being Worked On For GCC, GCC 9 Deadline Looms

    Back in September Code Sourcery / Mentor Graphics posted their new Radeon GCN port for the GNU Compiler Collection (GCC). Two months later this port is still being worked on but not yet ready for mainline.

    This Radeon GCN back-end for GCC is being done with a focus on GPU computing with eventually a goal of allowing OpenMP / OpenACC offloading to newer AMD GPUs. At this current stage, single-threaded C and Fortran programs can be built for Radeon GPUs with this compiler but the multi-threading API offloading bits are still coming about. This back-end has been focused on Fiji/Tonga support and newer.

  • AMDVLK Vulkan Driver Sees Its First Tagged Release

    In the nearly one year that the AMDVLK official Vulkan driver has been open-source there hasn't been any "releases" but rather new code drops on a weekly basis that is pushed out of their internal development repositories. But surprisingly this morning is now a v2018.4.1 release tag for this open-source AMD Vulkan Linux driver.

    The AMDVLK public source repositories have just been perpetual Git while AMD pulls from their internal repositories when building out their official closed-source Windows/Linux Radeon Software driver releases (that also use their closed-source shader compiler currently rather than the open-source AMDGPU LLVM back-end, as used by the public AMDVLK sources). Waking up this morning there is now the first release tag in AMDVLK as v2018.4.1.

  • Mesa Drops Support For AMD Zen L3 Thread Pinning, Will Develop New Approach

    It was just a few months back that the Mesa/RadeonSI open-source AMD Linux driver stack received Zen tuning for that CPU microarchitecture's characteristics. But now AMD's Marek Olšák is going back to the drawing board to work on a new approach for Zen tuning.

    Just a few days ago I wrote about another developer wanting to toggle the support around L3 thread pinning as it was found to hurt the RadeonSI Gallium3D performance in at least some Linux games. At that point the goal was to allow making it a DriConf tunable that could then be adjusted a per-game/app basis, but it turns out the gains aren't there to keep it around.

  • Mesa Gets Testing Patches For New Zen Optimization Around Thread Pinning

    It was just yesterday that the AMD Zen L3 thread pinning was dropped from Mesa due to that optimization not panning out as intended for benefiting the new AMD processors with the open-source Linux graphics driver stack. Lead Mesa hacker Marek Olšák is already out with a new Zen tuning implementation that may deliver on the original optimization goal.

    The first patch posted by Marek as part of his new tuning effort is to regularly re-pin the driver threads to the core complex (CCX) where the application thread is. Basically, when Mesa is being used without the glthread (OpenGL threading) behavior, keep chasing the application/game thread on the processor so it will be part of the same CCX and share a cache. This chasing is done rather than explicitly pinning the application thread.

  • The Shiny New Features Of Mesa 18.3 For Open-Source Intel / Radeon Graphics Drivers

    Being well into the Mesa 18.3 feature freeze and that quarterly update to these open-source OpenGL/Vulkan drivers due out in about two weeks, here is a look at all of the new features and changes you can expect to find with this big update.

  • NVIDIA released a new 415.13 beta driver recently for Linux

    One I completely forgot to post about here, NVIDIA recently released the 415.13 beta driver for Linux.

    Released on the 8th of November, it includes a number of interesting fixes, including an issue fixed with WINE where it might crash on recent distribution releases. Nice to see WINE get some focus, since things like this can affect Valve's Steam Play.

16-Way AMD EPYC Cloud Benchmark Comparison: Amazon EC2 vs. SkySilk vs. Packet

Filed under
Graphics/Benchmarks

With last week Amazon Web Services rolling out AMD EPYC cloud instances to EC2, I figured it would be an interesting time for a fresh benchmark look at how the AMD Linux cloud performance compares from some of the popular cloud providers. For this article are sixteen different instances benchmarked while looking at the raw performance as well as the value on each instance type relative to the benchmark performance and time consumed for the on-demand spot instancing. EPYC instances were tested from Amazon EC2, Packet.com, and SkySilk.

Read more

The Performance Impact Of Spectre Mitigation On POWER9

Filed under
Graphics/Benchmarks

Over the past year we have looked extensively at the performance impact of Spectre mitigations on x86_64 CPUs but now with having the Raptor Talos II in our labs, here are some benchmarks to see the performance impact of IBM's varying levels of Spectre mitigation for POWER9.

By default, Raptor Computing Systems ships their system in the safest mode of providing full kernel and user-space protection against Spectre Variant Two. But by editing a file from the OpenBMC environment it's possible to control the Spectre protections on their libre hardware. Besides the full/user protection against Spectre there is also kernel-only protection that is more akin to the protection found on x86_64 CPUs. Additionally, there is the ability to completely disable the protection for yielding the greatest performance (or what would be considered standard pre-2018) but leaving your hardware vulnerable to Spectre. More details on controlling the Spectre protections on Talos II hardware can be found via the RaptorCS.com Wiki.

Read more

Kernel and Graphics: EXT4, AMDGPU and Mesa

Filed under
Graphics/Benchmarks
Linux
  • EXT4 Getting Many Fixes In Linux 4.20, Including For Some Really Old Leaks

    Last month I reported on a number of fixes for really old bugs in the EXT4 code with some of the issues dating back to the Linux 2.6 days in the EXT3 file-system code that was carried over to the EXT4 driver. Those fixes are now working their way into the Linux 4.20 stable kernel. 

    Ted Ts'o sent out a fixes pull request today containing 18 patches. Sixteen of those patches are from Vasily Averin who was nailing these really old bugs/leaks. Of them, Ted noted, "A large number of ext4 bug fixes, mostly buffer and memory leaks on error return cleanup paths."

  • AMDGPU DRM-Next Driver Picks Up Support For Vega 20 "A1" Stepping

    Among the work queuing in the AMDGPU DRM-Next branch for what will in turn appear with the next kernel cycle (Linux 4.21) is support for Vega 20 A1 ASICs.

    The current Linux 4.20 cycle appears to have good support for Vega 20 GPUs at least from our tracking without having any access to the GPUs for now, but it looks like the production graphics cards will be on a new "A1" stepping rather than A0 that was used for the bring-up of this first 7nm Vega GPU.

  • Gallium D3D9 "Nine" Support Gets New Patches To Help Fight Lag Without Tearing

    While most Linux gamers these days are mesmerized by DXVK for mapping Direct3D 10/11 to Vulkan for better handling Windows games on Linux, for those with older Direct3D 9 era games there is still the Gallium Nine initiative for D3D9 implemented as a Mesa Gallium state tracker. A new patch series posted this weekend will make that Gallium Nine experience even better.

    Axel Davy who has been the lead developer on the Gallium D3D9 state tracker posted a set of two patches that allow the thread_submit=true option to be used with tearfree_discard=true option.

Syndicate content

More in Tux Machines

Thunderbird version 60.3.1 now Available, Includes Fixes for Cookie Removal and Encoding Issues

Thunderbird happens to be one of the most famous Email client. It is free and an open source one which was developed by the Mozilla Foundation back in 2003, fifteen years ago. From a very basic interface, it has come a long way to be what it is today in 2018. With these updates, a recent one into the 60.x series from the 52.x series was a significant one. While the 60.x (60.3.0) update started rolling out, Mozilla was keen to push out 60.3.1. This new version of Thunderbird had a few bugs and kinks here and there which needed to be addressed which Mozilla did, most of them at least. Read more

Games: Feral Interactive, ATOM RPG, Lore Finder, UnDungeon, Humble Store Fall Sale

Another Fine Update Cycle From Microsoft

  • Windows 10 1809's new rollout: Mapped drives broken, AMD issues, Trend Micro clash
    Within days of Microsoft's first release of Windows 10 1809 at the beginning of October, IT pros noticed that Windows File Explorer indicated that mapped network drives appeared to be broken. "Testing the new 1809 update, and everything seems to be fine except all mapped drives to Windows 2012 file servers show disconnected (red x) after reboots or logoff/on," wrote one IT pro on October 5, with many others confirming the same issue on company networks.
  • Windows 10’s October 2018 Update Breaks Mapped Network Drives
    Microsoft’s October 2018 Update drama is largely over, but there are still a few lingering bugs. Microsoft has confirmed an issue where mapped network drives are broken after a PC restarts. This will not be fixed until 2019.

Linux 4.20 Showing Some Performance Slowdowns

Being well past the Linux 4.20 merge window I have moved onto benchmarking more of this development version of the Linux kernel. Unfortunately, there are some clear performance regressions. This week I got to firing off some Linux 4.20 kernel benchmarks... I started with the AMD Ryzen Threadripper 2990WX and Intel Core i9 7980XE for being the interesting HEDT CPUs in my possession at the moment. On the 7980XE I spotted several performance regressions with this Linux 4.20 development kernel compared to Linux 4.19 and 4.18, so then I fired up the completely separate Intel Core i9 7960X box to carry out the same tests. Sure enough, with that different hardware, there is further confirmation of slowdowns with Linux 4.20. The common trait of these systems was Ubuntu 18.10 x86_64 and using the Linux 4.18.18, 4.19.1, and 4.20 Git kernel packages provided by the Ubuntu Mainline Kernel PPA. With the differing hardware the intention is not to compare the performance between the systems but in looking at the direction of the Linux kernel performance. Read more