Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

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.

NVIDIA Open-Sources New I2C USB Type-C Turing GPU Driver In Linux 4.20

Filed under
Graphics/Benchmarks
OSS

The Linux 4.20 kernel has just received a new post-merge-window new driver: i2c-nvidia-gpu that is being contributed by the NVIDIA crew for their newest Turing graphics cards.

While it's great seeing NVIDIA contribute code for their latest generation graphics hardware to the mainline Linux kernel, i2c-nvidia-gpu comes down to just being a bus driver for the USB Type-C controller that is accessible over I2C. These newest NVIDIA graphics cards have a USB Type-C port for next-gen VR headsets using the VirtualLink standard. VirtualLink allows for four HBR3 DP lanes, USB 3.1 data, and up to 27 Watts of power over this slim cable -- much better than the mess of cables currently needed for VR headsets.

Read more

Mesa 18.3 RC2

Filed under
Graphics/Benchmarks
  • mesa 18.3.0-rc2

    The second release candidate for Mesa 18.3.0 is now available.

  • Mesa 18.3-RC2 Released With RADV, Wayland & NIR Fixes

    The second weekly release candidate of Mesa 18.3 is now available for testing of these open-source OpenGL / Vulkan drivers.

    Mesa 18.3-RC2 comes with several RADV Radeon Vulkan driver fixes, Wayland WSI updates, a few Intel/NIR changes, some minor Android updates, Gallium Nine built with Meson now is linked against pthreads, and various other alterations.

The Polaris/Vega Performance At The End Of Mesa 18.3 Feature Development

Filed under
Graphics/Benchmarks

With Mesa 18.3 feature development having wrapped up at the end of October, here are some benchmarks showing how the updated RadeonSI and RADV drivers are performing for this code that is now under a feature freeze before its official release around the end of November. AMD Radeon Vega and Polaris graphics cards were tested with a slew of NVIDIA graphics cards also tested on their respective driver to show where the Linux gaming GPU performance is at as we head into the 2018 holiday shopping season.

Read more

Raptor Talos II POWER9 Benchmarks Against AMD Threadripper & Intel Core i9

Filed under
Graphics/Benchmarks

For those curious about the performance of IBM's POWER9 processors against the likes of today's AMD Threadripper and Intel Core i9 HEDT processors, here are some interesting benchmarks as we begin looking closer at the POWER9 performance on the fully open-source Raptor Talos II Secure Workstation. This open-source, secure system arrived for Linux testing with dual 22-core POWER9 CPUs to yield 176 total threads of power.

As mentioned a few days ago in the aforelinked article, Raptor Computing Systems recent sent over a Talos II system for benchmarking to deliver more frequent benchmarks from this high-end workstation/server that's fully open-source down to the motherboard firmware and BMC stack. We previously have carried out some remote benchmarks of the Talos II, but now having it in our labs allows us to more frequently conduct tests as well as swapping out the hardware, matching other test systems, and also other tests like performance-per-Watt comparisons that were not possible with the remote testing.

Read more

Syndicate content

More in Tux Machines

Linux 4.20--rc76

Well, that's more like it. This is a *tiny* rc7, just how I like it. Maybe it's because everybody is too busy prepping for the holidays, and maybe it's because we simply are doing well. Regardless, it's been a quiet week, and I hope the trend continues. The patch looks pretty small too, although it's skewed by a couple of bigger fixes (re-apply i915 workarounds after reset, and dm zoned bio completion fix). Other than that it's mainly all pretty small, and spread out (usual bulk of drivers, but some arch updates, filesystem fixes, core fixes, test updates..) Read more Also: Linux 4.20-rc7 Kernel Released - Linux 4.20 Should Be Released In Time For Christmas

Android Leftovers

1080p Linux Gaming Performance - NVIDIA 415.22 vs. Mesa 19.0-devel RADV/RadeonSI

Stemming from the recent Radeon RX 590 Linux gaming benchmarks were some requests to see more 1080p gaming benchmarks, so here's that article with the low to medium tier graphics cards from the NVIDIA GeForce and AMD Radeon line-up while using the latest graphics drivers on Ubuntu 18.10. This round of benchmarking was done with the GeForce GTX 980, GTX 1060, GTX 1070, and GTX 1070 Ti using the newest 415.22 proprietary graphics driver. On the AMD side was using the patched Linux 4.20 kernel build (for RX 590 support) paired with Mesa 19.0-devel via the Padoka PPA while testing the Radeon RX 580 and RX 590. Read more

Sparky SU 0.1.0

This tool provides Yad based front-end for su (spsu) allowing users to give a password and run graphical commands as root without needing to invoke su in a terminal emulator. It can be used as a Gksu replacement to run any application as root. Read more