Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

FreeBSD ZFS vs. Linux EXT4/Btrfs RAID With Twenty SSDs

Filed under
Graphics/Benchmarks

With FreeBSD 12.0 running great on the Dell PowerEdge R7425 server with dual AMD EPYC 7601 processors, I couldn't resist using the twenty Samsung SSDs in that 2U server for running some fresh FreeBSD ZFS RAID benchmarks as well as some reference figures from Ubuntu Linux with the native Btrfs RAID capabilities and then using EXT4 atop MD-RAID.

Read more

AMD Linux News

Filed under
Graphics/Benchmarks
Linux
  • AMD Squeezes In Some Final AMDGPU Changes To DRM-Next For Linux 4.21

    Complementing all of the AMDGPU feature work already staged for the upcoming Linux 4.21 kernel, another (small) batch of material was sent out on Wednesday.

    This latest AMDGPU material for Linux 4.21 includes PowerPlay updates for newer Polaris parts, a cursor plane update fast path, enabling GPU reset by default for Sea Islands (GCN 1.1) graphics cards, and various fixes.

  • AMD Adding STIBP "Always-On Preferred Mode" To Linux

    Initially during the Linux 4.20 kernel merge window with the STIBP addition for cross-hyperthread Spectre V2 mitigation it was turned on by default for all processes. But that turned out to have a sizable performance hit so the behavior was changed to only turn it on for processes under SECCOMP or when requested via the PRCTL interface. However, AMD is landing a patch that for select CPUs will have an always-on mode as evidently that's preferred for some AMD processors.

  • Radeon Software for Linux 18.50 Released - Just One Listed Change

    The Radeon Software for Linux 18.50 driver release (a.k.a. "AMDGPU-PRO" 18.50) is now officially available

    We were expecting the 18.50 driver update following Thursday's Radeon Software Adrenalin 2019 Edition driver for Windows having debuted. The 18.50 driver release has since been made available via the AMD web-site.

  • Radeon ROCm 1.9.1 vs. NVIDIA OpenCL Linux Plus RTX 2080 TensorFlow Benchmarks

    Following the GeForce RTX 2080 Linux gaming benchmarks last week with now having that non-Ti variant, I carried out some fresh GPU compute benchmarks of the higher-end NVIDIA GeForce and AMD Radeon graphics cards. Here's a look at the OpenCL performance between the competing vendors plus some fresh CUDA benchmarks as well as NVIDIA GPU Cloud TensorFlow Docker benchmarks.

  • Radeon Software Adrenalin 2019 Rolls Out While Linux Users Should Have AMDGPU-PRO 18.50

    AMD today released their Radeon Software Adrenalin 2019 Edition geared for Windows gamers while Linux users should have AMDGPU-PRO 18.50 available shortly for those wanting to use this hybrid Vulkan/OpenGL driver component that does also feature the AMDGPU-Open components too in their stable but dated composition.

    The 2019 Adrenalin Edition for Windows brings performance improvements for select Windows titles, new advisors to help configure games and settings, improved fan control, WattMan improvements, game streaming improvements, and more.

A Look At The Clear Linux Performance Over The Course Of 2018

Filed under
Graphics/Benchmarks

With the end of the year quickly approaching, it's time for our annual look at how the Linux performance has evolved over the past year from graphics drivers to distributions. This year was a particularly volatile year for Linux performance due to Spectre and Meltdown mitigations, some of which have at least partially recovered thanks to continued optimizations landing in subsequent kernel releases. But on the plus side, new releases of Python, PHP, GCC 8, and other new software releases have helped out the performance. For kicking off our year-end benchmark comparisons, first up is a look at how Intel's performance-optimized Clear Linux distribution evolved this year.

For getting a look at the performance, on four different systems (two Xeon boxes, a Core i5, and Core i7 systems), the performance was compared from Clear Linux at the end of 2017 to the current rolling-release state as of this week.

Read more

Mesa 19.0 and Mesa 18.2.7 Updates

Filed under
Graphics/Benchmarks

Radeon ROCm 1.9.1 vs. NVIDIA OpenCL Linux Plus RTX 2080 TensorFlow Benchmarks

Filed under
Graphics/Benchmarks

Following the GeForce RTX 2080 Linux gaming benchmarks last week with now having that non-Ti variant, I carried out some fresh GPU compute benchmarks of the higher-end NVIDIA GeForce and AMD Radeon graphics cards. Here's a look at the OpenCL performance between the competing vendors plus some fresh CUDA benchmarks as well as NVIDIA GPU Cloud TensorFlow Docker benchmarks.

This article provides a fresh look at the Linux GPU compute performance for NVIDIA and AMD. On the AMD side was the Linux 4.19 kernel paired with the ROCm 1.9.1 binary packages for Ubuntu 18.04 LTS. ROCm continues happily running well on the mainline kernel with the latest releases, compared to previously relying upon the out-of-tree/DKMS kernel modules for compute support on the discrete Radeon GPUS. ROCm 2.0 is still supposed to be released before year's end so there will be some fresh benchmarks coming up with that OpenCL 2.0+ implementation when the time comes. The Radeon CPUs tested were the RX Vega 56 and RX Vega 64 as well as tossing in the R9 Fury for some historical context.

Read more

Graphics: Wayland's Weston, AMD, GitLab, NVIDIA

Filed under
Graphics/Benchmarks
  • Wayland's Weston Switching Over To The Meson Build System

    Complementing the Meson build system support for Wayland itself, the Weston reference compositor now has been Meson-ized.

    Pekka Paalanen and Daniel Stone, both of Collabora, have landed the Meson build system support for the Weston compositor. At this stage the new build system should be fully working and correct.

  • AMDGPU DC Gets Polaris Corruption Fix, Some Code Refactoring

    AMD has published their latest batch of "DC" Display Core patches for the AMDGPU Linux kernel driver.

    This batch of 45 patches against this display code for the AMDGPU Direct Rendering Manager driver has some code cleanups and refactoring, changes some error messages to just warnings, and has a display corruption fix affecting some Polaris hardware.

  • Investigating GitLab

    The Direct Rendering Manager (DRM) kernel subsystem is a fairly small part of the kernel, he said. It is also a fairly small part of the open-source graphics stack, which is under the X.Org umbrella. DRM sits in the middle between the two, so the project has learned development tools and workflows from both of the larger projects.

    The kernel brought DRM into the Git world in 2006, which was just a year after Git came about; it was a "rough ride" back then, Vetter said. With Git came "proper commit messages". Prior to that, the X.org commit messages might just be a single, unhelpful line; now those messages explain why the change is being made and what it does. The idea of iterating on a patch series on the mailing list came from the kernel side as did the "benevolent dictator" model of maintainership. DRM, the X server, Wayland, and others all followed that model along the way.

    From the X.Org side came things like the committer model; in Mesa, every contributor had commit rights. That model has swept through the graphics community, so now DRM, the X server, and Wayland are all run using that scheme. Testing and continuous integration (CI) is something that DRM has adopted from X.Org; the kernel also does this, but DRM has adopted the X.Org approach, tooling, and test suites. For historical reasons, "almost everything" is under the MIT license, which comes from X.Org projects as well.

    There has been a lot of movement of tools and development strategies in both directions via the DRM subsystem. He thinks that using GitLab may be "the next big wave of changes" coming from the user-space side to kernel graphics, and maybe to the kernel itself eventually. This won't happen this year or next year, Vetter predicted, but over the next few years we will see GitLab being used more extensively.

  • AMDGPU For Linux 4.20 Gets The Final Radeon RX 590 Fix, Adds The New Vega PCI IDs

    With just over one week to go until the expected Linux 4.20 kernel release, Alex Deucher of AMD today sent in the latest batch of fixes to the DRM tree for landing at the end of this cycle.

    Notable about this latest set of "fixes" for the AMDGPU kernel graphics driver are:

    - The final Radeon RX 590 fix so this newer Polaris GPU no longer hangs under load. So once this Linux 4.20 material is merged to mainline, this month-old Polaris graphics card should now be happily running on Linux -- assuming you also have the latest Polaris firmware files and a recent version of Mesa. See our Radeon RX 590 benchmarks article for more details.

  • AMDVLK 2018.Q4.4 Driver Update Brings Performance Improvements, New Vulkan Bits

    AMD developers today outed their latest "AMDVLK" open-source Vulkan driver code drop dubbed AMDVLK 2018.Q4.4.

  • NVIDIA 415.23 Driver Fixes Build Issues Against Linux 4.20 Kernel

    The NVIDIA 415.23 driver was issued just to fix a build issue against the near-final Linux 4.20 kernels. In particular, there has been a build failure around the vm_insert_pfn function that is now worked around when building the NVIDIA proprietary driver's shim against the Linux 4.20 release candidates.

  • NVIDIA Now Shipping The Jetson AGX Xavier Module

    NVIDIA has been shipping the Jetson AGX Xavier Developer Kit the past few months while now they are beginning to ship the AGX Xavier Module intended for use in next-generation autonomous machines.

Kernel and Graphics: Linux I/O Schedulers, Btrfs, Intel, Mesa 18.3.1 and More

Filed under
Graphics/Benchmarks
Linux
  • Linux I/O Schedulers

    The Linux kernel I/O schedulers attempt to balance the need to get the best possible I/O performance while also trying to ensure the I/O requests are "fairly" shared among the I/O consumers.  There are several I/O schedulers in Linux, each try to solve the I/O scheduling issues using different mechanisms/heuristics and each has their own set of strengths and weaknesses.

    For traditional spinning media it makes sense to try and order I/O operations so that they are close together to reduce read/write head movement and hence decrease latency.  However, this reordering means that some I/O requests may get delayed, and the usual solution is to schedule these delayed requests after a specific time.   Faster non-volatile memory devices can generally handle random I/O requests very easily and hence do not require reordering.

  • Btrfs Restoring Support For Swap Files With Linux 4.21

    The Btrfs file-system hasn't supported Swap files on it in early a decade, but that support will be restored again with the upcoming Linux 4.21 kernel. 

    Btrfs hasn't supported Swap files on it since 2009 thus making swap partitions necessary unless having a mix of file-systems on your box (or not caring about any swap capabilities), but now with Linux 4.21 that support will be restored for allowing swap files to be reside on Btrfs.

  • Intel's IWD Linux Wireless Daemon 0.13 Adds Opportunistic Wireless Encryption

    Intel's promising IWD open-source wireless daemon continues picking up additional functionality in its trek towards potentially replacing wpa_supplicant. Out this week is IWD 0.13. 

    With the IWD 0.13 release there are fixes as well as support for Opportunistic Wireless Encryption and support for the common EAP-TLS framework.

  • Intel Developing "oneAPI" For Optimized Code Across CPUs, GPUs, FPGAs & More

    Intel's 2018 Architecture Day was primarily focused on the company's hardware architecture road-map, but one of the software (pre)announcements was their oneAPI software stack. 

  • Intel Working On Open-Sourcing The FSP - Would Be Huge Win For Coreboot & Security

    Intel's Architecture Day on Tuesday was delightfully filled with an overwhelming amount of valuable hardware information, but Intel's software efforts were also briefly touched on too. In fact, Raja Koduri reinforced how software is a big part of Intel technology and goes in-hand with their security, interconnect, memory, architecture, and process pillars and that's where their new oneAPI initiative will fit in. But what learning afterwards was most exciting on the software front.

  • Linux Is Already In Good Shape For The New Features Of Intel Gen11 Graphics & Icelake

    Besides seeing Icelake demos at the Intel Architecture Day that were running on Ubuntu, with closely tracking the Linux kernel's development most of the new features presented for Sunny Cove and Gen11 graphics have already been merged or at least available in patch form for some months within the Linux ecosystem. Here's a look at the features talked about yesterday and their state on Linux.

  • Intel Details Gen11 Graphics & Sunny Cove For Icelake

    At Intel's architecture day, the company finally detailed their "Gen 11" graphics that we've been seeing open-source Linux graphics driver patches for many months (Intel OTC posted their initial open-source display driver code in early January and has continued the enablement work since) albeit elusive in substantive user details and hardware until Icelake. But today at least we can share more about the significant improvements with Gen11 graphics.

  • mesa 18.3.1

    This version disables the VK_EXT_pci_bus_info extension due to last minute issues spotted in the specification.

  • Mesa 18.3.1 Released To Disable Botched Vulkan Extension

    Mesa 18.3 was released less than a week ago while today Mesa 18.3.1 was issued due to an error in the Vulkan specification.

    The motivating factor for this quick Mesa 18.3.1 release was to disable the VK_EXT_pci_bus_info extension that had just been introduced weeks ago. The Vulkan working group mistakenly assumed that PCI domains are 16-bit even though they could potentially be 32-bit values. The next Vulkan spec update will change the relevant structure to be 32-bit, which is a backwards-incompatible change.

  • High resolution wheel scrolling on Linux v4.21

    Most wheel mice have a physical feature to stop the wheel from spinning freely. That feature is called detents, notches, wheel clicks, stops, or something like that. On your average mouse that is 24 wheel clicks per full rotation, resulting in the wheel rotating by 15 degrees before its motion is arrested. On some other mice that angle is 18 degrees, so you get 20 clicks per full rotation.

    Of course, the world wouldn't be complete without fancy hardware features. Over the last 10 or so years devices have added free-wheeling scroll wheels or scroll wheels without distinct stops. In many cases wheel behaviour can be configured on the device, e.g. with Logitech's HID++ protocol. A few weeks back, Harry Cutts from the chromium team sent patches to enable Logitech high-resolution wheel scrolling in the kernel. Succinctly, these patches added another axis next to the existing REL_WHEEL named REL_WHEEL_HI_RES. Where available, the latter axis would provide finer-grained scroll information than the click-by-click REL_WHEEL. At the same time I accidentally stumbled across the documentation for the HID Resolution Multiplier Feature. A few patch revisions later and we now have everything queued up for v4.21. Below is a summary of the new behaviour.

    The kernel will continue to provide REL_WHEEL as axis for "wheel clicks", just as before. This axis provides the logical wheel clicks, (almost) nothing changes here. In addition, a REL_WHEEL_HI_RES axis is available which allows for finer-grained resolution. On this axis, the magic value 120 represents one logical traditional wheel click but a device may send a fraction of 120 for a smaller motion. Userspace can either accumulate the values until it hits a full 120 for one wheel click or it can scroll by a few pixels on each event for a smoother experience. The same principle is applied to REL_HWHEEL and REL_HWHEEL_HI_RES for horizontal scroll wheels (which these days is just tilting the wheel). The REL_WHEEL axis is now emulated by the kernel and simply sent out whenever we have accumulated 120.

  • Nouveau Lands Initial Open-Source NVIDIA Turing Support - But No GPU Acceleration

    Just in time for the upcoming Linux 4.21 kernel, the developers working on the reverse-engineered, open-source support for NVIDIA GeForce RTX "Turing" GPUs have published their preliminary code. But before getting too excited, there isn't GPU hardware acceleration working yet.

    Ben Skeggs of Red Hat spearheaded this enablement work. He's got the initial support working right now for the TU104 and TU106 chipsets, but not yet TU102 due to hardware access. The TU106 is the RTX 2060/2070 series while the TU104 is the GeForce RTX 2080 and the TU102 is the RTX 2080 Ti and TITAN RTX. Back on launch day the Nouveau community crew started their Turing reverse-engineering work. NVIDIA doesn't support nor hinder the Nouveau driver work, though these days do sample hardware to the developers and are occasionally able to answer technical questions for them.

ODROID-XU4: Much Better Performance Than The Raspberry Pi Plus USB3 & Gigabit Ethernet @ $60

Filed under
Graphics/Benchmarks

Hardkernel recently sent over the ODROUD-XU4 for benchmarking. This ARM SBC that just measures in at about 82 x 58 x 22 mm offers much better performance than many of the sub-$100 ARM SBCs while also featuring dual USB 3.0 ports, Gigabit Ethernet, eMMC storage, and is software compatible with the older XU3 ARM SBCs. Here's a look at the performance of the ODROID-XU4 compared to a variety of other single board computers.

This ~$60+ ARM single board computer is built around a Samsung Exynos5422 SoC that features four Cortex-A15 cores at 2.0GHz and four Cortex-A7 cores at 1.3GHz while the graphics are provided by a Mali-T628.

Read more

An Initial Look At The Intel Iris Gallium3D Driver Performance

Filed under
Graphics/Benchmarks

One of the most exciting developments in the open-source Intel driver space this year was the Iris Gallium3D driver taking shape as what's destined to eventually succeed their "classic" i965 Mesa driver. With Iris Gallium3D maturing, here's a look at how the performance currently stacks up to their mature OpenGL driver.

The Intel Iris Gallium3D driver is designed for Skylake (potentially Broadwell too) support and newer generations while being a forward-looking driver and utilizes their mature NIR compiler support. Iris holds much more performance potential than their classic Mesa driver albeit the developers haven't really taken to performance optimizations yet but rather getting the driver up and running, eliminating test suite failures, and getting to the point of feature parity with the i965 driver.

Read more

Graphics: V3D, AMD/Vega, Flicker-Free Boot

Filed under
Graphics/Benchmarks
  • V3D Compute, VC4 display, PM

    For V3D last week, I resurrected my old GLES 3.1 series with SSBO and shader imgae support, rebuilt it for V3D 4.1 (shader images no longer need manual tiling), and wrote indirect draw support and started on compute shaders. As of this weekend, dEQP-GLES31 is passing 1387/1567 of tests with “compute” in the name on the simulator. I have a fix needed for barrier(), then it’s time to build the kernel interface. In the process, I ended up fixing several job flushing bugs, plugging memory leaks, improving our shader disassembly debug dumps, and reducing memory consumption and CPU overhead.

  • AMD Outs New Vega 10 & 20 IDs With Linux Driver Patch

    AMD may have accidentally revealed some new products containing its Radeon RX Vega 10 and Radeon RX Vega 20 graphics technologies. The company patched its RadeonSI Mesa and AMDKFD/AMDGPU kernel drivers with new PCI IDs; no other changes were made with the patch.

    Phoronix reported that the patch added six new IDs released to Vega 10: 0x6869, 0x686A, 0x686B, 0x686D, 0x686E, and 0x686F. These are new IDs that were previously only referenced in an update to macOS Mojave and GPUOpen's lists of GFX9 parts. That could mean AMD plans to introduce new Vega 10 products sooner than later, but the company might also be internally testing new products that are a ways from release.

  • AMD Files Trademark For Vega II

    It looks like AMD could be announcing Vega II as new 7nm Vega GPUs soon complementing the recently announced Vega 20 Radeon Instinct MI50 / MI60 accelerators.

  • Arch Linux Users With Intel Graphics Can Begin Enjoying A Flicker-Free Boot

    It looks like the recent efforts led by Red Hat / Fedora on providing a flicker-free Linux boot experience and thanks to their upstream-focused approach is starting to pay off for the other desktop Linux distributions... A flicker-free boot experience can now be achieved on Arch Linux with the latest packages, assuming you don't have any quirky hardware. 

    A Phoronix reader reported in earlier today that Arch Linux as of the 4.19.8-arch1-1-ARCH kernel is working out well for the seamless/flicker-free boot experience. The caveat though -- like with Fedora -- is that it only works with Intel graphics hardware/driver for now and does require setting the "i915.fastboot=1" kernel module parameter.

Syndicate content