Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Graphics: RADV Vulkan Driver, NVIDIA 410.78 Linux Driver, Mesa 18.2.5, Firefox Nightly on Wayland and AMD Radeon RX 590 Launches

Filed under
Graphics/Benchmarks
  • RADV Vulkan Driver To Enable Vega Primitive Binning By Default - Helps Performance

    The RadeonSI OpenGL driver offered Vega primitive binning support the past year followed by the RADV Vulkan driver, but it hadn't been enabled by default. Those working on the RADV driver are now planning on unconditionally enabling this Vega performance optimization for up to a few percent performance boost.

    It seems the primitive binning driver support for RADV is mature enough that it can be flipped on by default and at least doesn't appear to be hurting any prominent Vulkan-powered Linux games. Samuel Pitoiset of Valve's Linux driver team sent out the patch today for flipping it on by default. On that patch message he describes this Vega feature as helping out some games by a few percent, "After doing a bunch of benchmarks, primitive binning helps some games like The Talos Principle (+5%) or Serious Sam 2017 (+3%). For other titles, either it doesn't change anything or it hurts very few (less than 1%)."

  • NVIDIA 410.78 Linux Driver Fixes Vulkan Corruption, Adds Quadro RTX 4000 Support

    For those using the NVIDIA long-lived 410 Linux driver series over the in-beta 415.xx driver series, the 410.78 driver release is out today as the newest stable binary driver build.

    The NVIDIA 410.78 rolls out with official support for the Quadro RTX 4000 graphics card and a handful of bug fixes. The bug fixes include addressing a possible X Server hang when using legacy VGA mode, mode-setting failure with SDI output, and Vulkan rendering corruption.

  • [Mesa-dev] [ANNOUNCE] mesa 18.2.5

    A patch for nine state tracker that fixes several crashes using nine's thread_submit feature. There are other patches to other state trackers.

    A couple of patches for Meson build system, as well as for autotools.

    In the drivers side, there are a couple of fixes for RADV, one regarding subgroups and another regarding conditional rendering. There are also fixes for virgl, r600, and i965.

  • Mesa 18.2.5 Brings Fixes For Direct3D 9 State Tracker, RADV Vulkan Driver

    For those sticking to the Mesa stable release train, Mesa 18.2.5 is now available ahead of the Mesa 18.3 quarterly feature release due out in the weeks ahead.

    As is the case for Mesa point releases, Mesa 18.2.5 is geared to deliver the latest bug/regression fixes. this 18.2.5 release has around three dozen changes, including fixes for the Gallium "Nine" D3D9 state tracker when using its thread-submit functionality, Meson build system updates, RADV Vulkan driver fixes, and also some basic fixes/tweaks to the common NIR, Mesa, and Intel code. There is no particular standout prominent fixes unless you were personally affected by one of the bugs.

  • Firefox Nightly now with experimental Wayland support

    As of last nightly (20181115100051), Firefox now supports Wayland on Linux, thanks to the work from Martin Stransky and Jan Horak, mostly.

    Before that, it was possible to build your own Firefox with Wayland support (and Fedora does it), but now the downloads from mozilla.org come with Wayland support out of the box for the first time.

    However, being experimental and all, the Wayland support is not enabled by default, meaning by default, you’ll still be using XWayland. To enable wayland support, first set the GDK_BACKEND environment variable to wayland.

  • AMD Radeon RX 590 Launches, Linux Support Presumably Okay

    While it comes as no surprise given all the leaks in recent weeks, today AMD officially announced the Radeon RX 590 graphics card as another update to Polaris.

    The new Polaris PCI ID addition we spotted back in September indeed turned out to be for a new high-end Polaris refresh. The Radeon RX 590 is this new high-end Polaris graphics card that is manufactured on a 12nm FinFET process.

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

Syndicate content