Language Selection

English French German Italian Portuguese Spanish


LLVM Clang Performance Matching The GCC Compiler On AMD Threadripper 3960X

Filed under

Last week were some benchmarks showing LLVM Clang hitting ~96% the performance of GCC using Intel Ice Lake while now for the recently released Zen2-based AMD Ryzen Threadripper 3960X we are seeing results where overall LLVM Clang is now at performance parity to GCC.

This round of compiler testing was done on the AMD Ryzen Threadripper 3960X 24-core processor atop Ubuntu 19.10 with the Linux 5.4 kernel. The tested compilers were GCC 9.2.1, GCC 10.0 development snapshot from this month, LLVM Clang 9.0.0, and LLVM Clang 10.0.0. All four compilers were built in their release mode. The CFLAGS/CXXFLAGS when building the benchmarks under test were set at "-O3 -march=native" throughout testing.

Read more

Graphics: Mesa/LLVMpipe, DragonFlyBSD and NVIDIA

Filed under
  • Mesa 20.0's LLVMpipe Now Supports Running OpenCL On The CPU

    Mesa's LLVMpipe Gallium3D driver has long been about running OpenGL on GPUs as a software fallback / debug path but as of this morning in Mesa 20.0-devel there is now the experimental ability of having OpenCL support making use of OpenCL "Clover" with NIR for CPU-based execution.

    LLVMpipe recently introduced the ability to use the NIR intermediate representation over TGSI. Following that NIR transition, it ended up being quite easy to get OpenCL support going making use of the "Clover" Gallium3D state tracker for OpenCL. Clover recently picked up NIR support thanks to the work by Red Hat on the Nouveau side and their open-source NVIDIA compute efforts.

  • DragonFlyBSD Updates Its Intel Graphics Driver From Linux 4.8.17

    The Linux 4.8 series is over three years old while now the DragonFlyBSD crew has pulled in the Linux 4.8.17 sources of the Intel "i915" DRM driver into their kernel for providing updated graphics driver coverage.

    For roughly two years the DragonFlyBSD kernel has been making use of modified Linux 4.7~4.8 kernel code for their Intel Direct Rendering Manager driver adaptation. With this update against the newer point release code, DragonFlyBSD desktop users with Intel graphics should be seeing better support.

  • If you have an old NVIDIA 8 or 9 series GPU, there's a new Linux driver update out for you

    While naturally a lot of the focus for a GPU vendor is on their latest and greatest, NVIDIA do still support many of their older GPUs on Linux.

    This month they put out the 340.108 driver, which supports some of their classics like the GeForce 9800 and GeForce 8800 GTX plus many older.

6 Useful Linux Apps to Stress Test and Benchmark CPU Performance

Filed under

Benchmark and stress test methods are often used to gauge the performance of desktop PCs and servers. These tests are also useful in finding hardware problems and system anomalies that are observed only when a system is under heavy load.

This article will list various utilities to perform CPU benchmarks and stress tests on your system. While many of these apps provide options to test other hardware components as well, this article will focus on CPU tests only.

Read more

Blender And V-Ray CPU Rendering: Linux vs. Windows

Filed under

Desktop users have always cared about software optimization, and as soon as many-core CPUs began to hit the market, it became immediately clear that not all software is developed alike. In the classic Linux vs. Windows performance debate, another element is thrown in with the fact that software optimizations can differ between OSes, ultimately making it difficult to predict which route would be quicker.

When AMD released its second-gen Ryzen Threadripper last year, its top-end model offered 32 cores, and 64 threads. At launch, many reviewers encountered performance anomalies, but in some cases, those anomalies proved to be nonexistent in Linux. An explicit example we remember is with 7-zip; its built-in benchmark didn’t scale well with the 2990WX in Windows, but did just fine in Linux.

Since the release of those (now last-gen) Threadrippers, both Linux and Windows have received updates to improve threading on big CPUs, and improve performance on their respective platforms in general. Windows has clearly needed more polish than Linux, given that it wasn’t until this past summer when AMD could consider its quest for optimal threading complete. That contrasts with our entire Linux suite scaling pretty well from the get-go.

Read more

Graphics: NVIDIA, Intel, DisplayLink and AMD

Filed under
  • NVIDIA Releases 340.108 Linux Driver Providing Updated Legacy Support For GeForce 8 / 9

    For those still running a GeForce 8 or 9 series graphics card, you really ought to consider upgrading this holiday season. Even the cheapest of recent generation NVIDIA GPUs should deliver better performance and far better efficiency over those older GPUs, but in any case, NVIDIA released the 340.108 Linux driver as part of their legacy maintenance support.

    The NVIDIA 340.108 Linux legacy driver update has better compatibility with the latest kernels through v5.4, various installer fixes, and a variety of other build-related failures to let this legacy driver continuing to run gracefully on the latest Linux distributions as we enter 2020. There are no new features with this being an old legacy branch simply in maintenance mode.

  • Intel Sends Out A Big Christmas Update Of Graphics Driver Changes Aiming For Linux 5.6

    Intel's open-source graphics driver team responsible for their kernel graphics driver (the i915 Direct Rendering Manager driver) have sent out their first (big) batch of new material to DRM-Next for collection ahead of the Linux 5.6 merge window opening in just over one month's time.

  • Hybrid graphics and DisplayLink docks create laptop Linux pain

    Not that it is ever likely to happen, but if the fabled Year of the Linux desktop were ever to begin to occur, its momentum would more than likely crash against laptops with hybrid graphics.

    These are devices that pack a discrete GPU, usually Nvidia, and couple it with the standard laptop-style integrated graphics. It's a best of both worlds approach that relies on the integrated graphics silicon to save power, and the kicking in of the discrete GPU when workloads demand it.

    That's the theory anyway.

    In recent weeks, a pair of laptops with such display technology landed in ZDNet's South Pacific outpost, the Gigabyte Aero 15 OLED and the Lenovo ThinkPad X1 Extreme Gen 2.

    Both laptops have 9th generation Intel CPUs, NVMe-based storage, and 15.6-inch screens. But the Gigabyte has a tasty 4K OLED display along with a beefy Nvidia GeForce RTX 2070, and 8GB of RAM, while the ThinkPad has a HD-capable screen with a GeForce GTX 1650, and 16GB of memory.

    With a flashy rainbow-lit keyboard, the Aero comes across as a gaming machine that could get away with a few productivity and creative applications.

  • AMDVLK 2019.Q4.5 Vulkan Driver Adds A Couple More Extensions

    AMD's official Vulkan driver team has pushed a new code drop of their open-source Linux "AMDVLK" derivative for those wanting to give it a whirl for some holiday gaming.

    The AMDVLK 2019.Q4.5 is the surprise release out this Monday morning, compared to usually doing their code drops later in the week. The AMDVLK 2019.Q4.5 driver now exposes Vulkan 1.1.129 API and adds support for the VK_KHR_shader_float_controls and VK_KHR_separate_depth_stencil_layouts extensions.

KDE vs XFCE vs Gnome

Filed under

Chris Titus recently vlogged about an article showing that KDE 5.17 is now smaller than XFCE 4.14 in memory usage. The article says that in their tests, XFCE actually uses more RAM than KDE. I was very interested in this, but I couldn’t quite believe it and so I ran my own tests.

First of all, we need to compare apples to apples. I created an OpenSUSE VM using Vagrant with KVM/libvirt. It had 4 cores and 4192MB of RAM. This VM has no graphical interface at all. As soon as I got it up, I took the first “No X” measurement. After patching using zypper dup, I took the second “No X” reading. Every reading in this blog post was using the free -m command. I then shut down the VM and cloned it 3 times so each copy should be completely the same.

I installed the desktop environments into their respective VMs using the following commands:

zypper in -t pattern kde

zypper in -t pattern xfce

zypper in -t pattern gnome
After desktop environment was done, I then installed the lightdm display manager. This wasn’t actually necessary with Gnome because it installs gdm as a dependency.

Read more

Latest Benchmarks Behind Partial Paywalls: Compilers, Vulkan/Radeon and SVT-AV1

Filed under
  • LLVM Clang Achieves ~96% The Performance Of GCC On Intel Ice Lake

    The LLVM Clang compiler continues becoming increasing competitive against the long-standing GNU Compiler Collection (GCC) on Linux x86_64 systems... With tests done on Intel Ice Lake using the Core i7-1065G7, the Clang 9.0 stable performance is delivering over 95% the performance of GCC 9 stable based on over 40 C/C++ benchmarks.

    Recently I wrapped up some LLVM Clang vs. GCC stable Linux x86_64 benchmarks using the Core i7-1065G7 "Ice Lake" processor and was quite impressed with the results for how close Clang was competing with GCC.

  • The Performance Advancements Of The Radeon Open-Source OpenGL/Vulkan Drivers Over 2019

    This comparison featured the same hardware tested under Ubuntu 18.10 for a representative end-of-2018 experience to then the latest driver stack using Ubuntu 19.10 and migrating to the Linux 5.5 Git kernel and Mesa 20.0-devel via the Oibaf PPA. Tests this year were done using a Radeon RX 580 Polaris and RX Vega 64 graphics cards given their support going back to the end of 2018, which obviously ruled out testing the likes of Navi or Vega 20 for this comparison. Additionally, the games/software tested were limited to OpenGL and Vulkan games working nicely going back to the end of 2018, thus ruling out some of the 2019 Linux game ports that required Mesa 19.x.

    The same hardware was used and this basically amounts to a straight-forward look at how the OpenGL and Vulkan AMD Linux drivers within Mesa have evolved over the course of 2019. In the case of the RADV Vulkan driver, the end-of-2019 tests were done both out-of-the-box and then when enabling Valve's ACO compiler back-end alternative to AMDGPU LLVM, which can further help the gaming performance at large but is currently not enabled by default.

    Besides better performance, the RadeonSI OpenGL driver this year recently picked up OpenGL 4.6 support in Mesa 20.0-devel and with that also enabling NIR usage by default. Various new extensions are supported by both the AMD open-source OpenGL and Vulkan drivers.

  • Intel SVT-AV1 0.8 AV1 Video Encoding Benchmarks

    On Friday Intel released SVT-AV1 0.8 with more AVX2/AVX-512 optimizations for this one of the fastest CPU-based AV1 open-source video encoders (and growing decoding support too). Here are some benchmarks of SVT-AV1 0.8 compared to the previous v0.7 release on various Intel and AMD systems.

    Over the weekend I started tossing SVT-AV1 0.8 on various systems via the Phoronix Test Suite / for seeing how the performance compares to the previous Scalable Video Technology AV1 encoder release. The Ubuntu Linux systems picked spanned various generations but mostly a random assortment of hardware based upon convenience for this one-page weekend testing. The systems included the Intel Core i7 1065G7, Core i7 7740X, Core i9 9900KS, Xeon E5-2687W v3, dual Xeon Gold 6138, dual Xeon Platinum 8280 on the Intel side. On the AMD side was the Ryzen 5 3600X, Threadripper 3960X, EPYC 7601, and dual EPYC 7742.

Intel Graphics and Benchmarks

Filed under
  • Intel Adding DRM-Based Scaling Filter Support For Wayland's Weston For Less Blurry Outputs

    Intel contributions to Wayland/Weston aren't as frequent as years ago, but they continue volleying interesting work to keep pace with their graphics driver and Direct Rendering Manager subsystem advancements. Their latest work is on adding scaling filter support to libweston in order to supporting filters like nearest-neighbor for yielding less blurry outputs when upscaling.

  • Intel Still Has The Upperhand On BSD Support - Core i9 10980XE Benchmarks With DragonFlyBSD + FreeBSD

    While the AMD Ryzen Threadripper 3970X is delivering better raw Linux performance in a far majority of workloads compared to the Intel Core i9 10980XE, one of the areas where the Cascadelake-X platform and Intel CPUs still have an advantage is when it comes to the BSD support. Intel actively supports the BSDs more than AMD and in turn leads to the latest hardware generally working out fine on the latest BSDs. Here are some DragonFlyBSD and FreeBSD tests against Linux with the i9-10980XE.

    In the case of the Threadripper 3970X on the BSDs, it works fine with FreeBSD 12.1 but failed with DragonFlyBSD. Generally with new AMD platforms the latest FreeBSD releases stand good chances of working out-of-the-box but routinely are new motherboards/chipsets that play quirky with FreeBSD or lack various working driver support. On the DragonFlyBSD side the support generally isn't there at-launch due to whatever bugs for a given launch, but are generally addressed with time, especially with DragonFlyBSD lead developer Matthew Dillon being a big Ryzen/Threadripper fan and has routinely expressed his fondness for their recent platforms. But with AMD not dedicating much in the way of visible resource helping the BSDs, new Intel hardware support is usually better positioned to work on the BSDs at launch. It's not that no big AMD customers use BSDs but in cases like Netflix, they optimized FreeBSD themselves.

Graphics: XWayland/Wayland, Vulkan, LunarG and AMD

Filed under
  • XWayland Gets Tidied Up Ahead Of The Holidays For The Eventual X.Org Server 1.21

    Sadly there still is no release plan for getting the long overdue X.Org Server 1.21 out the door and at this point is looking increasingly unlikely that it would land for Ubuntu 20.04 LTS. But at least this extra time for X.Org Server 1.21 has allowed more XWayland changes to flow in.

    There has been recent XWayland work like multi-buffering, other stuttering issues, RandR/Vidmode emulation, and a variety of other enhancements.

  • Wayland's Weston 8.0 Reaches Beta With Direct-Display Extension, Partial Updates, HDCP

    Following the Weston 8.0 Alpha release from earlier this month, the Weston 8.0 Beta is now available for this reference Wayland compositor.

    Weston 8.0 features include items like handling EGL partial screen updates, a direct display extension in conjunction with DMA-BUF buffers being submitted directly to the display controller, HDCP support is now wired into the Direct Rendering Manager back-end, XYUV format support with OpenGL, the ability to double-load Weston modules, support for using OpenGL rendering with the head-less back-end, and many other changes.

  • [ANNOUNCE] weston 7.0.92
    This is the beta release for weston 8.0.0. Full commit history below.
    Daniel Stone (1):
          CI: Bump ci-templates dependency for working pip
    Emmanuel Gil Peyrot (2):
          backend-drm: Remove unused variable
          backend-drm: Make boolean fields actually bool
    Leandro Ribeiro (3):
          clients/window: drop support for rgb565
          screen-share: define variable type before using as function argument
          backend-rdp: report a zero physical size to compositor
    Marius Vlad (1):
          clients/simple-dmabuf-egl: Add some notes when using direct-display
    Michael Forney (1):
          clients/presentation-shm: Add missing dependency on xdg-shell protocol
    Pekka Paalanen (8):
          xwm: add newline to cardinal array
          xwm: debug _XWAYLAND_ALLOW_COMMITS
          xwm: debug what kind decoration is drawn
          xwm: xcb_configure_window() takes uint16_t
          xwm: debug ConfigureWindow
          gitlab-ci: image build should fail on failed commands
          gitlab-ci: wrap and alphabetize apt-get line
          gitlab-ci: install xwayland
    Simon Ser (1):
          build: bump to version 7.0.92 for the beta release
    Stefan Agner (2):
          renderer: change all frame_signal emission to pass previous_damage
          backend-drm: Define potentially missing aspect-ratio bit definitions
    git tag: 7.0.92
  • Vulkan 1.1.130 SDK Released - GFX Reconstruct Continues Path To Replace Vktrace/Vkreplay

    LunarG on Friday released the Vulkan SDK 1.1.130 version with an updated license, better validation layer coverage, and support for newer extensions.

    Newer Vulkan extensions now supported include VK_EXT_tooling_info, VK_KHR_buffer_device_address, VK_KHR_performance_query, and VK_KHR_separate_depth_stencil_layouts.

  • LunarG Releases New SDKs for Vulkan

    LunarG has released new Vulkan SDKs for Windows, Linux, and macOS based on the header. This release includes maintenance updates, the latest extensions, and a link to the new Vulkan License Registry.


    The vktrace and vkreplay tools currently included in this SDK will be removed in the next 3-6 months. It will be replaced with GFX Reconstruct. Vktrace/vkreplay will still be available via a github repository but will not be included in future SDKs.

  • Radeon ROCm 3.0 Released With LLVM "AOMP" For Radeon OpenMP, FFT Updates

    Announced last month at SuperComputing 19 in Denver was Radeon Open Compute 3.0 (ROCm 3.0) but it didn't end up shipping until last night. ROCm 3.0 is a big update to AMD's open-source Linux compute stack for ending out 2019.

  • Gallium3D's LLVMpipe Lands NIR Support Plus Radeon R600g NIR Support Is Forthcoming

    More Mesa drivers continue to be embracing NIR as the modern intermediate representation shared between these OpenGL and Vulkan open-source implementations.

    Besides the Intel drivers leading the NIR transition along with smaller drivers like Freedreno and VC4, RADV has been making use of NIR and now RadeonSI is working on transitioning to it while TGSI currently remains the default. The LLVMpipe Gallium3D software rasterizer is the newest in-tree Mesa driver making use of this IR.

    With commits that were merged over night for Mesa 20.0-devel, NIR is now a supported intermediate representation alongside TGSI for this driver that commonly serves as an OpenGL fallback driver on the Linux desktop.

Opening up Mali T720

Filed under

If you have a device with a Mali T720 or T820 GPU, you’re in luck – your device is now supported in upstream Mesa at feature parity with other GPUs. Get out your Allwinner H6 or Amlogic S912 board, grab the latest Mesa, and enjoy a match of SuperTuxKart with fully free and open source mainline drivers!

When Panfrost began, we focused on the highest performance Mali GPUs found in Chromebooks. By contrast, Mali GPUs like T720 are designed for simplicity, where minimizing size is more important than maximizing performance.

Simplicity for the hardware, that is. For us, those changes mean new complexity – but we’re up to the challenge. Over the past month, Collaboran Tomeu Vizoso and I reverse-engineered the Mali T720 and adapted Panfrost for the new devices.

Much of our work focused on the tiler. As I blogged about over the summer, Mali GPUs are “tiling” architectures, meaning they divide the screen into many small “tiles” or “bins” and operate on those smaller sections of the screen to save memory bandwidth and improve power efficiency. The fastest Mali architectures use “hierarchical tiling”, where many different sizes of tiles are used at once. But this tiler is simplified, with no support for hierarchical tiling. Instead, the driver selects a single tile size used for the entire screen; the new model requires new driver changes. Fortunately after my work on hierarchical tiling over the summer, we were able to figure out the non-hierarchical tiler and then implement our findings in Panfrost with ease.

Read more

Syndicate content