Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Ryzen 9 3900X vs. Ryzen 9 3950X vs. Core i9 9900KS In Nearly 150 Benchmarks

Filed under
Graphics/Benchmarks

This week our AMD Ryzen 9 3950X review sample finally arrived and so we've begun putting it through the paces of many different benchmarks. The first of these Linux tests with the Ryzen 9 3950X is looking at the performance up against the Ryzen 9 3900X and Intel Core i9 9900KS in 149 different tests.

The Ryzen 9 3950X is AMD's new $749 USD processor just below the Threadripper 3960X. The 3950X offers sixteen cores / 32 threads with a 3.5GHz base clock and 4.7GHz maximum turbo clock. Over the 3900X at $499 is four extra cores / eight threads, a 300MHz lowering of the base clock, 100MHz higher maximum boost clock, and larger L1 and L2 caches while both of these Zen 2 processors share the same TDP of 105 Watts.

Read more

Also: Ryzen CPUs On Linux Finally See CCD Temperatures, Current + Voltage Reporting

Intel graphics patch "wrecks" Gen7 iGPU Linux performance

Filed under
Graphics/Benchmarks
  • Intel graphics patch "wrecks" Gen7 iGPU Linux performance

    Earlier this week Intel released details about a vulnerability in its integrated graphics hardware. Its advisory ID was INTEL-SA-00314 and it talked about the CVE-2019-14615 vulnerability. Products from 3rd Gen Core up to 10th Gen are affected including the contemporaneous Xeon, Pentium, Celeron and Atom products. Intel was made aware of this vulnerability as far back as August so already has patches available and links to recommended new drivers for both Windows and Linux users (scroll down this page about half way).

    All so regular and nothing surprising so far… However, since the updated drivers have been released, Linux-centric tech site Phoronix has been busy checking and testing the new drivers (on Linux of course) to see if there are any performance penalties, or other aberrations, delivered with the vulnerability patches.

    Intel describes the CVE-2019-14615 vulnerability as follows: "Insufficient control flow in certain data structures for some Intel Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via local access." Please note the key phrase - local access - but Phoronix thinks that WebGL within web browsers is another possible attack vector.

    In its Linux testing, Phoronix was initially unperturbed by results on processors sportin

  • Intel's Mitigation For CVE-2019-14615 Graphics Vulnerability Obliterates Gen7 iGPU Performance

    Yesterday we noted that the Linux kernel picked up a patch mitigating an Intel Gen9 graphics vulnerability. It didn't sound too bad at first but then seeing Ivy Bridge Gen7 and Haswell Gen7.5 graphics are also affected raised eyebrows especially with that requiring a much larger mitigation. Now in testing the performance impact, the current mitigation patches completely wreck the performance of Ivybridge/Haswell graphics performance.

    The vulnerability being discussed and analyzed this week is CVE-2019-14615. This CVE still hasn't been made public over 24 hours later (though there are the Intel SA-00314 details for this disclosure), but from going through kernel patches and other resources, it certainly caught our interest right away and have been benchmarking it since yesterday evening. The CVE-2019-14615 vulnerability amounts to a new information disclosure issue due to insufficient control flow in certain data structures. Local access is required for exploiting this control flow issue in the hardware, but it's not yet known/published if say WebGL within web browsers could exploit this issue. This is a hardware issue with all operating systems being affected. Our testing today, of course, is under Linux.

Raspberry Pi 4 V3D Driver Reaches OpenGL ES 3.1 Conformance

Filed under
Graphics/Benchmarks
Hardware
  • Raspberry Pi 4 V3D Driver Reaches OpenGL ES 3.1 Conformance

    The V3D Gallium3D driver that most notably offers the open-source graphics support for the Raspberry Pi 4 is now an official OpenGL ES 3.1 implementation.

    Consulting firm Igalia has continued working on the V3D driver since Eric Anholt left Broadcom. Igalia had ironed out OpenGL ES 3.1 support and last month also went on to begin tackling geometry shaders and more.

  • Iago Toral: I am working on the Raspberry Pi 4 Mesa V3D driver

    Yeah… this blog post is well overdue, but better late than never! So yes, I am currently working on progressing the Raspberry Pi 4 Mesa driver stack, together with my Igalian colleagues Piñeiro and Chema, continuing the fantastic work started by Eric Anholt on the Mesa V3D driver.

    The Raspberry Pi 4 sports a Video Core VI GPU that is capable of OpenGL ES 3.2, so it is a big update from the Raspberry Pi 3, which could only do OpenGL ES 2.0. Another big change with the Raspberry Pi 4 is that the Mesa v3d driver is the driver used by default with Raspbian. Because both GPUs are quite different, Eric had to write an all new driver for the Raspberry Pi 4, and that is why there are two drivers in Mesa: the VC4 driver is for the Raspberry Pi 3, while the V3D driver targets the Raspberry Pi 4.

  • Raspberry Pi 4 V3D driver gets Geometry Shaders

    I actually landed this in Mesa back in December but never got to announce it anywhere. The implementation passes all the tests available in the Khronos Conformance Tests Suite (CTS). If you give this a try and find any bugs, please report them here with the V3D tag.

  • Raspberry Pi 4 V3D driver gets OpenGL ES 3.1 conformance

    So continuing with the news, here is a fairly recent one: as the tile states, I am happy to announce that the Raspberry Pi 4 is now an OpenGL ES 3.1 conformant product!. This means that the Mesa V3D driver has successfully passed a whole lot of tests designed to validate the OpenGL ES 3.1 feature set, which should be a good sign of driver quality and correctness.

    It should be noted that the Raspberry Pi 4 shipped with a V3D driver exposing OpenGL ES 3.0, so this also means that on top of all the bugfixes that we implemented for conformance, the driver has also gained new functionality! Particularly, we merged Eric’s previous work to enable Compute Shaders.

Graphics: CVE-2019-14615, Mir 1.7 Release, Panfrost Talk ("Liberating ARM GPUs")

Filed under
Graphics/Benchmarks
  • Red Hat Recommends Disabling The Intel Linux Graphics Driver Over Hardware Flaw

    It's been another day testing and investigating CVE-2019-14615, a.k.a. the Intel graphics hardware issue where for Gen9 all turned out to be okay but for Gen7 graphics leads to some big performance hits. Besides the Core i7 tests published yesterday in the aforelinked article, tests on relevant Core i3 and i5 CPUs are currently being carried out for seeing the impact there (so far, it's looking to be equally brutal).

    The contents of CVE-2019-14615 are still marked private, but the Red Hat Customer Portal has opened their guidance on this graphics flaw. Red Hat rates this CVE as having moderate impact. This Red Hat bug report does shed some more light onto the issue.

  • Mir 1.7 Released With Improvements For Running X11 Software

    Mir 1.7 was released today as the newest feature release for this Ubuntu-focused display stack that for the past two years now has focused on serving viable Wayland support.

    With the Mir 1.7 release there are a number of X11 client improvements, including the ability to show basic window decorations, a new configuration knob for specifying the XWayland executable to utilize for the support, and various code clean-ups.

  • Panfrost: Liberating ARM GPUs @ Linux Conf Au

    This talk covers the history, future and internals of the Panfrost driver for ARM GPUs.

Intel's Mitigation For CVE-2019-14615 Graphics Vulnerability Obliterates Gen7 iGPU Performance

Filed under
Graphics/Benchmarks

Yesterday we noted that the Linux kernel picked up a patch mitigating an Intel Gen9 graphics vulnerability. It didn't sound too bad at first but then seeing Ivy Bridge Gen7 and Haswell Gen7.5 graphics are also affected raised eyebrows especially with that requiring a much larger mitigation. Now in testing the performance impact, the current mitigation patches completely wreck the performance of Ivybridge/Haswell graphics performance.

The vulnerability being discussed and analyzed this week is CVE-2019-14615. This CVE still hasn't been made public over 24 hours later (though there are the Intel SA-00314 details for this disclosure), but from going through kernel patches and other resources, it certainly caught our interest right away and have been benchmarking it since yesterday evening. The CVE-2019-14615 vulnerability amounts to a new information disclosure issue due to insufficient control flow in certain data structures. Local access is required for exploiting this control flow issue in the hardware, but it's not yet known/published if say WebGL within web browsers could exploit this issue. This is a hardware issue with all operating systems being affected. Our testing today, of course, is under Linux.

Read more

Graphics: Wayland 1.18.0 Coming, NVIDIA and Intel in Linux

Filed under
Graphics/Benchmarks
  • Wayland 1.18.0 release schedule
    Hi all,
    
    Here is the release schedule for Wayland 1.18.0:
    
    - Alpha: January 21st, in one week
    - Beta: January 28th
    - RC1: February 4th
    - First potential final release date: February 11th
    
    Package maintainers are encouraged to pick up the pre-releases to make
    sure packaging can be tested (and fixed) before the stable release.
    This is the first release to support the Meson build system. The
    autotools build is still supported for now, but will be dropped in a
    future version.
    
    Let me know if you'd like a pending patch to make it in the release.
    
    Thanks,
    
    Simon
    
  • Wayland 1.18 Planned For Release Next Month

    Without seeing a new release of Wayland itself in nearly one year, a plan has been rolled out for having Wayland 1.18 in mid-February.

    Simon Ser has stepped up to organize the Wayland 1.18 release and is planning for the alpha in one week, the Wayland 1.18 beta at month's end, and the release candidates to happen in February until the stable version is ready to ship. The release plan for Wayland 1.18 can be found on Wayland-dev.

  • There Is Finally Open-Source Accelerated NVIDIA Turing Graphics Support

    Here is another big feature coming for Linux 5.6: the Nouveau driver will have initial accelerated support for NVIDIA "Turing" GPUs! This is coming at long-last with NVIDIA set to release publicly the Turing firmware images needed for hardware initialization.

    As of writing, NVIDIA hasn't yet volleyed the signed firmware needed for Turing hardware initialization, but it appears advanced copies went out to Nouveau DRM maintainer Ben Skeggs of Red Hat. With the firmware bits and some DRM driver hacking, Skeggs now has the Turing GPUs lighting up with the open-source driver.

  • Intel Lands A Final Batch Of Graphics Driver Updates Ahead Of Linux 5.6

    Intel's open-source graphics driver crew has submitted a final batch of updates to DRM-Next ahead of the Linux 5.6 kernel merge window. The DRM-Next cut-off is this week ahead of the Linux 5.6 window opening up at the start of February.

    Over previous weeks into DRM-Next Intel has submitted various Tiger Lake and Jasper Lake updates, HDCP 2.2 support for Coffee Lake, Panel Self Refresh improvements, and various other enhancements.

Vulkan Graphics: Vulkan 1.2 and Beyond

Filed under
Graphics/Benchmarks
  • Vulkan 1.2 Arrives With An Eye On Greater Performance, Better Compatibility With Other 3D APIs On Top

    Coming up next month already will mark four years since the release of Vulkan 1.0 but for today is an early surprise... Vulkan 1.2! The Khronos Group has prepared Vulkan 1.2 for release as the newest major update to this graphics and compute API. Several vendors also have Vulkan 1.2 support in tow.

  • RenderDoc 1.6 Released, NVIDIA + AMD + Intel All Primed For Vulkan 1.2

    This morning's release of Vulkan 1.2 is off to a great start.

    To no surprise, NVIDIA is first out of the gate with a Vulkan 1.2 driver for Windows and Linux. The NVIDIA 440.48.02 Linux driver adds the Vulkan 1.2 support. Additionally, this Vulkan beta driver supports PRIME synchronization when paired with the Linux 5.4 kernel or newer.

  • Vulkan API specification 1.2 released, new NVIDIA Vulkan Beta driver up

    Today, The Khronos Group has released the next big update the Vulkan graphics API specification with Vulkan 1.2 now available. This marks almost four years since 1.0 specification release.

    Vulkan 1.2 pulls in 23 extensions into the core of the Vulkan API, bringing access to new hardware functionality, the possibility to improve performance and more. There's a lot of excitement around it, with multiple companies giving their support in the official press release here like Google for Stadia, Stardock Entertainment, NVIDIA, AMD, Arm, Intel and more.

    "Vulkan 1.2 brings together nearly two dozen high-priority features developed over the past two years into one, unified core Vulkan standard, setting a cutting-edge bar for functionality in the industry’s only open GPU API for cross-platform 3D and compute acceleration," said Tom Olson, distinguished engineer at Arm, and Vulkan working group chair. "Khronos will continue delivering regular Vulkan ecosystem updates with this proven, developer-focused methodology to both meet the needs and expand the horizons of real-world applications."

  • A Slew Of ACO Optimizations For The Radeon Vulkan Driver Landed In Mesa 20.0

    The Valve-backed ACO compiler back-end that is optionally used by the RADV Radeon Vulkan driver has continued growing in popularity with Linux gamers and also has continued maturing a lot for Mesa 20.0 that is due out later this quarter.

    On top of the work that has merged already for ACO since its original mainlining in Mesa 19.3, optimizations and fixes are aplenty for ACO with RADV come Mesa 20.0.

Graphics: CoreAVI, X.Org Server 1.20.7, Wayland Adds Meson Build System Support

Filed under
Graphics/Benchmarks
  • CoreAVI Achieves Formal Khronos OpenGL SC 1.0.1 Compliance Running its VkCoreGL SC1 Library

    Core Avionics & Industrial Inc. (“CoreAVI”) announced today that it has achieved formal Khronos Group compliance for its VkCoreGL™ SC1 (OpenGL SC 1.0.1) application library running on its Vulkan-based VkCore™ SC graphics and compute driver. Successful passing Khronos’ conformance testing process ensures implementation quality and provides implementor protection via the Khronos Intellectual Property Framework.Adhering to open software standards is a key part of CoreAVI’s philosophy and this compliance provides customers with the standards-based confidence they require for safety critical software products. CoreAVI is the chair of Khronos’ Vulkan Safety Critical Working Group to define a formal safety critical version of Vulkan and is continually focused on driving forward new standards to support true safety critical compute capabilities using graphics processors.

  • CoreAVI VkCoreGL SC1 Hits Compliance For Ushering Vulkan Into Safety Critical Systems

    Vulkan could soon be used indirectly on safety critical military and aerospace displays thanks to CoreAVI's VkCoreGL SC1.

    While there is a Vulkan safety-critical working group with aims similar to OpenGL SC, at the moment there is no released Vulkan SC specification. But Military and aerospace supplier CoreAVI (who is also involved in the Vulkan SC effort) has developed VkCoreGL SC1 as an OpenGL SC library running on top of Vulkan.

    VkCoreGL SC1 is for transitioning OpenGL safety critical applications onto Vulkan-based systems. VkCoreGL SC1 is similar to Mesa's Zink and the other projects implementing OpenGL over Vulkan but with CoreAVI's commercial offering they are implementing the OpenGL safety critical specification. As of today, they are now formally deemed in compliance with OpenGL SC 1.0.1.

  • xorg-server 1.20.7
    A variety of bugfixes, primarily in modesetting, glamor, and Solaris
    support. This release also contains support for choosing the DRI driver
    via EGL_MESA_query_driver. Thanks to all who contributed with testing
    and fixes!
    
    Aaron Plattner (1):
          modesetting: Check whether RandR was initialized before calling rrGetScrPriv
    
    Alan Coopersmith (5):
          os-support/solaris: Drop ExtendedEnabled global variable
          Add ddxInputThread call from os layer into ddx layer
          Add xf86OSInputThreadInit call from common layer into os-support layer
          os-support/solaris: Set IOPL for input thread too
          ospoll: Fix Solaris ports implementation to build on Solaris 11.4
    
    Kenneth Graunke (2):
          glamor: Add a function to get the driver name via EGL_MESA_query_driver
          modesetting: Use EGL_MESA_query_driver to select DRI driver if possible
    
    Matt Turner (1):
          xserver 1.20.7
    
    Michel Dänzer (5):
          modesetting: Call glamor_finish from drmmode_crtc_set_mode
          xfree86/modes: Call xf86RotateRedisplay from xf86CrtcRotate
          modesetting: Clear new screen pixmap storage on RandR resize
          xwayland: Do flush GPU work in xwl_present_flush
          glamor: Only use dual blending with GLSL >= 1.30
    
    Peter Hutterer (1):
          Xi: return AlreadyGrabbed for key grabs > 255
    
    git tag: xorg-server-1.20.7
    
  • X.Org Server 1.20.7 Released With A Handful Of Fixes For GLAMOR + Modesetting

    With no sign of X.Org Server 1.21 on the horizon, the X.Org Server 1.20 point releases continue rolling on.

    Intel Linux graphics developer Matt Turner stepped up to release X.Org Server 1.20.7 as the latest point release, consisting of fourteen changes. The changes are mostly centered on the GLAMOR and xf86-video-modesetting driver bits but also some Solaris updates via Oracle's Alan Coopersmith.

    NVIDIA's Aaron Plattner added a check to the xf86-video-modesetting DDX around verifying RandR initialization, Intel's Kenneth Graunke now has the modesetting driver using EGL_MESA_query_driver to select the DRI driver if possible (needed for their Iris driver), and a few other modesetting fixes are in there too. Graunke also added a change to GLAMOR for querying the driver name as well via EGL_MESA_query_driver, again, good news for their Iris Gallium3D driver.

  • Wayland Adds Meson Build System Support

    While Wayland's Weston reference compositor has been using the Meson build system for about the past year, only this week did Wayland itself see Meson support introduced.

    Wayland has added Meson build system support for the same reasons most projects do: faster build times, cleaner than GNU Autotools, and tends to work better on other platforms especially with Windows.

    GNOME's Emmanuele Bassi added the support. For now the Meson build system support is living alongside the Autotools support. The plan is to drop Autotools once the Meson support has proven to be at least on-par with the existing build system support.

Looking At The Linux Performance Two Years After Spectre / Meltdown Mitigations

Filed under
Graphics/Benchmarks

Last week marked the two year anniversary since the formal public disclosure of the Spectre and Meltdown disclosures. To commemorate that anniversary, I was running some fresh benchmarks of various Intel desktop and server processors with the in-development Ubuntu 20.04 LTS to look at the performance impact today with the default CPU vulnerability mitigations and then again with the mitigations disabled at run-time.

A daily snapshot of Ubuntu 20.04 LTS was used as of last week for offering the very latest look at the Linux performance two years after Spectre/Meltdown entered the public spotlight. Ubuntu 20.04 LTS right now is running on a Linux 5.4 based kernel, GCC 9.2.1, and the other latest stable packages.

Read more

Getting Started with Amlogic NPU on Khadas VIM3/VIM3L

Filed under
Graphics/Benchmarks

Shenzhen Wesion released the NPU toolkit for Khadas VIM3/VIM3L last November, so I decided to try the latest Ubuntu 18.04 image and the NPU toolkit on Khadas VIM3L, before switching to VIM3 for reasons I’ll explain below.

I’ve followed two tutorials from the forum and wiki to run pre-built samples and then building a firmware image and samples from source.

This will be obvious to anyone who read the specs for Khadas VIM3 and VIM3L that the former comes with a 5 TOPS NPU, while the one in the latter only delivers up to 1.2 TOPS. But somehow, I forgot about this, and assume both had the same NPU making VIM3L more attractive but this type of task, Obviously I was wrong.

But the real reason I stopped using Khadas VIM3L can be seen in the photo below.

Read more

Syndicate content

More in Tux Machines