Language Selection

English French German Italian Portuguese Spanish

Mesa 19.0 Released

Filed under
Graphics/Benchmarks
  • mesa 19.0.0
    Hi List,
    
    I'm pleased to announce the general availability of mesa 19.0.0. We've had a
    slightly long rc process with 7 RCs (there should have been 6, but there was a
    bug in the script for pulling patches resulting in two back to back RCs). In
    general this release has shaped up rather nicely, and I look forward to the
    stable release cycle.
    
    Of note is that autotools support is deprecated in 19.0.0, and you must now add
    --enable-autotools to autogen.sh and configure. If you haven't already **now**
    is the time to try meson, if all goes according to plan autotools will be
    removed before the 19.1 release.
    
    Dylan
    
    shortlog:
    Brian Paul (1):
          svga: remove SVGA_RELOC_READ flag in SVGA3D_BindGBSurface()
    
    Danylo Piliaiev (1):
          anv: Fix destroying descriptor sets when pool gets reset
    
    Dylan Baker (4):
          cherry-ignore: Update the cherry-ignore file
          VERSION: bump for 19.0.0 release
          docs: Add release notes for 19.0.0
          docs: Add SHA256 sums for 19.0.0
    
    Eric Anholt (1):
          st/dri: Set the PIPE_BIND_SHARED flag on create_image_with_modifiers.
    
    Erik Faye-Lund (1):
          virgl: remove unused variable
    
    Ian Romanick (2):
          intel/fs: nir_op_extract_i8 extracts a byte, not a word
          intel/fs: Fix extract_u8 of an odd byte from a 64-bit integer
    
    Jason Ekstrand (5):
          spirv: Pull offset/stride from the pointer for OpArrayLength
          anv: Refactor descriptor pushing a bit
          anv: Take references to push descriptor set layouts
          nir: Add a pass for lowering IO back to vector when possible
          intel/nir: Vectorize all IO
    
    Juan A. Suarez Romero (1):
          anv: destroy descriptor sets when pool gets reset
    
    Samuel Pitoiset (1):
          radv: fix pointSizeRange limits
    
    Tapani Pälli (3):
          anv: release memory allocated by glsl types during spirv_to_nir
          anv: revert "anv: release memory allocated by glsl types during spirv_to_nir"
          anv: destroy descriptor sets when pool gets destroyed
    
    pal1000 (1):
          scons: Compatibility with Scons development version string
          
  • Mesa 19.0 Graphics Stack Released for Linux Gamers with Numerous Improvements

    The team behind the Mesa 3D Graphics Library project announced today the final release and general availability of the long-anticipated Mesa 19.0 graphics stack series for Linux-based operating systems.

    Implementing the OpenGL 4.5 API, the Mesa 19.0 graphics stack is finally here after an extended development cycle that took place over the last three months. It brings dozens of new features, new extensions, and countless bug fixes. Highlights of this major new series includes support for AMD Radeon Vega 10, Vega 20, and Vega M GPUs, GNU Hurd support, and LLVM 7 compatibility.

  • Mesa 19.0 Released With Many Improvements To The Open-Source Vulkan/OpenGL Drivers

    Mesa 19.0 has finally been released! It's more than two weeks late, but it should be worth the wait given all the improvements in this quarterly feature update to this open-source graphics driver stack.

    The Mesa 19.0 features are plentiful with Intel's Vulkan driver now having transform feedback and many other additions, soft FP64/INT64 was merged to Mesa, the necessary bits are in place for RadeonSI FreeSync/Adaptive-Sync, AMD Zen thread optimizations, various new OpenGL extensions, Vega RADV primitive binning is enabled by default, and a variety of performance improvements and other OpenGL/Vulkan driver tuning.

  • Mesa 19.0 is officially out, lots of improvements for Linux open source graphics drivers

    Today is the day, for those of you using open source graphics drivers (AMD/Intel and some older NVIDIA GPUs), Mesa 19.0 is now officially out.

More in Tux Machines

AMD EPYC vs. Intel Xeon Cascadelake With Facebook's RocksDB Database

Following the benchmarks earlier this month looking at PostgreSQL 12.0 on AMD EPYC Rome versus Intel Xeon Cascade Lake there was interest from Phoronix readers in wondering how well Rome is doing for other modern enterprise database workloads. One of those workloads that was recently added to the Phoronix Test Suite / OpenBenchmarking.org is Facebook's RocksDB, the company's embedded database that is forked from Google LevelDB. With RocksDB being designed to exploit many CPU cores and modern SSD storage, here are some benchmarks looking at how the Xeon Platinum 8280 stacks up against various new AMD EPYC 7002 series processors. RocksDB is a key-value embedded database solution that Facebook has been working on since 2012 in taking Google's LevelDB to the next level of performance on modern CPU/SSD servers. RocksDB is in turn also used by companies like LinkedIn, Airbnb, Pinterest, Rakuten, Uber, and others. With RocksDB having its own performance-focused built-in benchmarks, it makes for some interesting performance comparisons on these server CPUs given its growing presence in the enterprise. Those unfamiliar with RocksDB can learn more at RocksDB.org. Read more

Review of Arch Linux-based Manjaro 18.1 and Zstd in Arch Linux

  • Review: Manjaro 18.1 "Juhraya"
  • Arch Linux Nears Roll-Out Of Zstd Compressed Packages For Faster Pacman Installs

    The upcoming release of Arch's Pacman 5.2 is bringing support for compressing packages with Zstd which ultimately will provide faster package installs on Arch Linux. Similar to other Linux distributions beginning to make use of Facebook's Zstd (Zstandard) compression algorithm for faster compression/decompression of packages, Arch Linux is doing the same. Their findings mirror that of others in allowing faster compression/decompression performance with a similar compression ratio for binaries to that of XZ.

GNOME Shell Development Updates

  • GNOME Shell + Mutter Begin Landing Graphene Integration

    Graphene is a lightweight library that has been in development by GNOME's Emmanuele Bassi. Graphene -- not to be confused with several other software projects sharing similar names -- is intended as a very lightweight library providing graphics types and their relative API while avoiding any windowing system bits and other functionality with this layer just focused on providing speedy vector operations. Graphene has fast paths for SSE2, ARM NEON, GCC Vector extensions, and other optimizations for optimally dealing with graphic data types like matrices, vectors and points. [...] With part 1, various geometry/point/rectangle/vector Clutter objects are replaced with Graphene code. Ultimately this should provide for better performance around various graphic data type operations while also cleaning up some of GNOME's low-level code in the process. This initial integration is now in place for the initial GNOME 3.35/3.36 series though expect more Graphene improvements to come now that the initial support and dependency are in place.

  • Gnome-shell Hackfest 2019 – Day 2

    Well, we are starting the 3rd and last day of this hackfest… I’ll write about yesterday, which probably means tomorrow I’ll blog about today :).

  • Gnome-shell Hackfest 2019 – Day 3

    As promised, some late notes on the 3rd and last day of the gnome-shell hackfest, so yesterday!

Graphics: Libdrm, AMDGPU, AR/VR and Gallium3D

  • Libdrm 2.4.100 Released With Bits For Intel Elkhart Lake, Tiger Lake Graphics

    AMD open-source developer Marek Olšák on Wednesday released libdrm 2.4.100 as the newest feature update to this Mesa DRM library. On the AMD front there are a number of RAS tests added, a new amdgpu_cs_query_reset_state2 interface, and other expanded AMDGPU test coverage.

  • AMDGPU GFX9+ Format Modifiers Being Worked On For Better DCC Handling

    RADV Vulkan driver developer Bas Nieuwenhuizen of Google has ventured into kernel space in working on format modifiers support for Vega/GFX9 and newer. This DRM format modifiers support for GFX9+ is being worked on for helping to evaluate when delta color compression (DCC) can be used and any other requirements around that DCC handling. Bas explained, "This is particularly useful to determine if we can use DCC, and whether we need an extra display compatible DCC metadata plane."

  • Free software support for virtual and augmented reality

    A talk at the recent X.Org Developers Conference in Montréal, Canada looked at support for "XR" in free software. XR is an umbrella term that includes both virtual reality (VR) and augmented reality (AR). In the talk, Joey Ferwerda and Christoph Haag from Collabora gave an overview of XR and the Monado project that provides support for those types of applications. Ferwerda started by defining the term "HMD", which predates VR and AR. It is a head-mounted display, which basically means "taking a screen and some sensors and duct-taping it to your face". All of the devices that are being used for XR are HMDs. They typically include some kind of tracking system to determine the position and orientation of the HMD itself. Multiple different technologies, including inertial measurement units (IMUs), photodiodes, lasers, and cameras, are used to do the tracking depending on the device and its use case. AR is intended to augment the real world with extra information; the user sees the real world around them, but various kinds of status and additional data is tagged to objects or locations in their view of the world. AR is a rather over-hyped technology these days, he said. The general idea is that users would wear glasses that would augment their view in some fashion, but, unfortunately, what most people think of as AR is Pokémon Go. VR uses two screens, one for each eye, to create a 3D world that the user inhabits and can interact with in some fashion. Instead of seeing the real world, the user sees a completely separate world. There are two words that are often used to describe the feel of VR, he said: "presence" and "immersion". That means users are aware of themselves as being part of the VR environment. XR encompasses both. Ferwerda said that he is not really sure what the "X" stands for; he has heard "cross reality" and "mixed reality" for XR. Haag said that "extended reality" was another definition that he had heard.

  • Intel Now Aiming For Gallium3D OpenGL Default For Mesa 20.0

    For the better part of two years now Intel has been working on this new "Iris" Gallium3D driver for supporting Broadwell "Gen8" graphics and newer as the eventual replacement to their long-standing i965 classic driver. With Tiger Lake "Gen12" Xe graphics, it's in fact Iris Gallium3D only. In our testing of Broadwell through the *lakes, this Gallium3D driver has been working out terrific on Mesa 19.2 stable and Mesa 19.3 development. But it looks like Intel is going to play it safe and punt the default change-over to next quarter's Mesa 20.0 cycle.