Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Linux 5.9 Performance Is Off To A Great Start With FSGSBASE Boost

Filed under
Graphics/Benchmarks
Linux

FSGSBASE particularly helps out context switching heavy workloads like I/O and allowing user-space software to write to the x86_64 GSBASE without kernel interaction. That in turn has been of interest to Java and others.

While going through patch review, we've benchmarked FSGSBASE patches at different points and found the performance benefits to be evident and helping in areas hurt by the likes of Spectre/Meltdown. FSGSBASE is supported on Intel CPUs since Ivy Bridge as well as newer AMD CPUs, where the performance is also helped.

On Linux 5.9 where FSGSBASE is finally mainlined, it's enabled by default on supported CPUs. FSGSBASE can be disabled at kernel boot time via the "nofsgsbase" kernel option. On Linux 5.9+, looking for "fsgsbase" in the /proc/cpuinfo is the indicator whether FSGSBASE kernel usage is happening though note prior to 5.9 on supported CPUs the "fsgsbase" string is always present.

For this article are some early data points of Linux 5.9 tested out-of-the-box on a Git snapshot and then again when booting that kernel image with "nofsgsbase" and repeating the tests. Via the Phoronix Test Suite various benchmarks relevant to FSGSBASE testing were carried out. Quick tests on both Intel Core and AMD Ryzen are done for this article while additional tests will be coming of Linux 5.9 over the weeks ahead -- 5.9-rc1 isn't even out until next weekend as marking the end of 5.9 features landing.

Read more

Also: User Xattr Support Finally Landing For NFS In Linux 5.9

Please pull NFS server updates for v5.9

Graphics: Mesa 20.2 RC, NVIDIA HPC SDK and Mike Blumenkrantz on Shader Testing

Filed under
Graphics/Benchmarks
  • mesa 20.2.0-rc1
    Hi list,
    
    The mesa 20.2 release cycle is officially underway! A new staging/20.2 and 20.2
    branch have been pushed, and 20.2.0-rc1 is now officially available for your
    consumption. Please enjoy responsibly.
    
    I'm still planning to have a normal -rc cadence on wednesdays. I do apologize if
    I'm a bit slow to respond, especially to email. Please ping me on matrix or irc
    if I've missed something from you.
    
    Dylan
    
  • Mesa 20.2 Development Ends After Many New Features Land

    Feature work on Mesa 20.2 is now over with the code having been branched today and Mesa 20.2-RC1 subsequently issued.

    There will now be weekly release candidates until this quarter's release is ready, which is likely to happen at some point in September depending upon how many blocker bugs are discovered and in turn how long it takes to get those issues resolved. Ideally the Mesa 20.2.0 release will happen in early September.

  • NVIDIA Releases Their Previously Announced HPC SDK

    Earlier this year at GTC Digital was the announcement of the NVIDIA High Performance Computing Software Development Kit while this week they have finally released this HPC SDK for developers at large.

    The NVIDIA HPC SDK aims to make it easy to deploy HPC workloads not only on NVIDIA GPUs but also CPUs. The HPC SDK features LLVM-based C++ and Fortran compilers, including support for automatic GPU acceleration of C++17 code using parallel algorithms and Fortran intrinsics.

  • Mike Blumenkrantz: Shader Testing

    I’m back, and today’s topic is testing.

    Again.

    But this time is different. This time I’m going to be looking into a specific test format, namely piglit shader tests.

    Shader tests in piglit are tests which are passed through piglit’s undocumented shader_runner binary, which parses *.shader_test files at runtime to automatically produce tests based on GLSL without requiring any actual GL code and only minimal boilerplate. This makes writing tests easy, and, more importantly for my own use case, it makes debugging them easier.

Graphics: Mesa 20.1.5, Intel and AMD

Filed under
Graphics/Benchmarks
  • mesa 20.1.5
    Hi all,
    
    I'd like to announce Mesa 20.1.5, the fifth bugfix release for the 20.1 branch.
    
    The next bugfix release is planned for 2 weeks from now, on 2020-08-19.
    
    Cheers,
    Eric
    
    
  • Mesa 20.1.5 Released For The Latest Stable Open-Source Vulkan / OpenGL Drivers

    Mesa 20.1.5 provides the latest stable open-source Vulkan/OpenGL graphics drivers for the Linux desktop as the newest bi-weekly milestone.

    Mesa 20.2 remains under development as this quarter's feature release due out in about one month's time. Mesa 20.2 is running behind schedule as it should have been branched around the end of July but has yet to happen. In any case, more Mesa 20.2 feature work continues to land and more than likely will ship sometime in September. But until that occurs, Mesa 20.1 is the latest stable series.

  • Intel Workaround For Graphics Driver Regression: "The Platform Problem Going Crazy"

    Sent out over the weekend was a patch series for the Intel Linux kernel graphics driver entitled "Time, where did it go?" This set of 42 patches aims to provide incremental improvements to the driver to offset a performance regression in Linux 5.7 that Intel hasn't been able to track down. This increased complication of the driver to offset the regression is now under the microscope.

    The set of 42 patches by longtime Intel open-source developer Chris Wilson provides incremental improvements to reduce the execution latency. He was upfront that the intent of these improvements are to "basically offsets the small regressions incurred when compared to [Linux kernel] 5.7."

  • RadeonSI Resorts To Disabling SDMA For GFX9/Vega Due To APU Issues

    AMD's RadeonSI Gallium3D driver has resorted to disabling SDMA (System DMA) async DMA engine support for all GFX9/Vega hardware due to issues plaguing some APUs.

    While SDMA has the potential of helping performance, GFX9 (Vega) is now seeing the support disabled due to bugs seeming to only affect APUs. Though it's not entirely surprising as the open-source AMD Radeon Linux driver also is not enabling SDMA at this point for GFX8 (Polaris) or GFX10 (Navi) hardware either.

    Opened three months ago was the merge request for disabling SDMA on GFX9 and to back-port it to the stable series as well. Longtime AMD open-source developer Marek Olsak noted, "This is somewhat a radical step. All opinions welcome."

Intel's Clear Linux Still Outperforming Other Distributions For Mid-2020

Filed under
Graphics/Benchmarks

Being well past the half-way point for the year, here is a look at how Intel's performance-optimized Clear Linux distribution is performing compared to its rolling state last December. Plus there are also benchmarks looking at how the current Clear Linux is performing against other rolling-release distributions.

Read more

Kernel and Graphics: Another Attack on the GPL, Power Management and Thermal Control Microconference, Intel and AMD

Filed under
Graphics/Benchmarks
Linux

  • Wrap it before you tap it? No, say Linux developers: 'GPL condom' for Nvidia driver is laughed out of the kernel

    Linux devs have dismissed a proposed patch to the kernel that would only work with a Nvidia driver, motivating a second patch that will prevent disguised use of proprietary code in GPL modules.

    The Linux Kernel licensing rules make provision for proprietary third-party modules but state that they must be tagged as such.

    This "cannot be used for modules with source code in the kernel tree. Modules tagged that way are tainting the kernel with the 'P' flag when loaded and the kernel module loader refuses to link such modules against symbols which are exported with EXPORT_SYMBOL_GPL()."

    Facebook developer Jonathan Lemon put forward an RFC (Request for Comments) on a proposal to implement DMA (Direct Memory Access) zero-copy between a network card and a GPU to enhance network performance, while keeping the protocol processing on the CPU. The use case is for "GPUs used for machine learning, which are located near the NICs, and have a high bandwidth PCI connection between the GPU/NIC," states the RFC.

    The code relies on Nvidia's proprietary driver for Linux, noticed by kernel maintainer Greg Kroah-Hartman, who observed: "OK, now you are just trolling us. Nice job, I shouldn't have read the previous patches. Please, go get a lawyer to sign-off on this patch, with their corporate email address on it. That's the only way we could possibly consider something like this."

  • Power Management and Thermal Control Microconference Accepted into 2020 Linux Plumbers Conference

    We are pleased to announce that the Power Management and Thermal Control Microconference has been accepted into the 2020 Linux Plumbers Conference!

    Power management and thermal control is an important area in the Linux ecosystem to help with the global environment. Optimizing the amount of work that is achieved while having long battery life and keeping the box from overheating is critical in today’s world. This meeting will focus on continuing to have Linux be an efficient operating system while still lowering the cost of running a data center.

    Last year’s meetup at Linux Plumbers resulted in the introduction of thermal pressure support into the CPU scheduler as well as several improvements to the thermal framework, such as a netlink implementation of thermal notification and improvements to CPU cooling. Discussions from last year also helped to improve systems-wide suspend testing tools.

  • Intel Tiger Lake OpenCL Support On Linux Now Considered Production Ready

    With all the recent work on Intel's open-source compute stack around the vector back-end and GPU code generation with their ISPC compiler there was another significant milestone achieved that went unnoticed until spotting the change a few days ago. 

    The open-source Intel Compute Runtime in the past two weeks now has "production" ready OpenCL support for the forthcoming Gen12 Tiger Lake graphics. That's good news with Tiger Lake laptops expected to market soon. 

  • RADV ACO Back-End Begins Tackling Navi 2 / GFX10.3 Support

    With the "Sienna Cichlid" and "Navy Flounder" open-source driver support as what appear to be the first "Navi 2" GPUs and the first of the "GFX10.3" generation on the graphics engine side there is the initial kernel support with Linux 5.9 and the initial Mesa support for 20.2. That Mesa support has been focused on RadeonSI as the official OpenGL driver as well as Mesa's RADV driver as the Radeon Vulkan driver in-tree but not officially supported by AMD. That RADV support is currently un-tested. Both drivers currently depend upon the "AMDGPU" back-end found in the forthcoming LLVM 11.0 with its initial GFX10.3 support. But now on the RADV driver side there is preliminary GFX10.3 bits landing for the popular "ACO" back-end. 

    ACO is the back-end worked on by Valve and other stakeholders like open-source graphics driver engineers from Google and Red Hat. But as ACO isn't officially supported by AMD, there hasn't been any patches from them in wiring up the Navi 2 / GFX10.3 support for this AMDGPU LLVM alternative. Rhys Perry as part of Valve's Linux driver efforts though has worked out what should be the initial changes needed for this yet-to-be-released hardware with ACO. 

Graphics: AMD, Intel and Wayland/Wayfire

Filed under
Graphics/Benchmarks
  • Defaulting Radeon GCN 1.0/1.1 GPUs To Better Linux Driver Is Held Up By Analog Outputs

    Switching from the "Radeon" to "AMDGPU" kernel driver on Linux is possible for Radeon GCN 1.0/1.1 era graphics cards and doing so can mean slight performance benefits, the ability to run the AMDVLK or RADV Vulkan drivers, and simply making use of this better maintained driver. But having these original GCN graphics cards default to the modern AMDGPU driver appears held up by the lack of analog video output support with that driver.

  • Intel's Open-Source H.265/HEVC Encoder Sees First Release Of 2020

    Intel's Scalable Video Technology team is known for their open-source video encoder work particularly on AV1 and VP9 formats, but they also continue to maintain a high performance H.265/HEVC encoder as well. Intel SVT-HEVC 1.5 was released on Monday as their first major update of the year.

    Intel SVT-HEVC 1.5 fixes "all memory leaks" following a refactoring of their allocation/deallocation code that also leads to the ability for FFmpeg to run multi-instance encoding in parallel. SVT-HEVC 1.5 also has a number of optimizations, fixes for a random hang issue with few threads (something we've seen as well with SVT-HEVC in our own benchmarks), and a number of other fixes.

  • GNOME's Mutter Adds Support For Launching "Trusted Clients" On Wayland

    Merged to GNOME's Mutter compositor is an API for Wayland to allow the launching of trusted clients.

    This "trusted clients" support is namely about allowing child windows to be signified as being from a parent window/process. This can also allow for some nifty use-cases for GNOME on Wayland. The patch explains:
    Unfortunately, although the child process can be a graphical program, currently it is not possible for the inner code to identify the windows created by the child in a secure manner (this is: being able to ensure that a malicious program won't be able to trick the inner code into thinking it is a child process launched by it).

  • Wayfire 0.5 Wayland Compositor Brings Latency Optimizations, More Protocols

    Wayfire, a Wayland compositor inspired by the likes of Compiz with different desktop effects, is out today with a new feature release.

    Perhaps most exciting with Wayfire 0.5 is the work done to improve (reduce) the latency. Wayfire now better tracks how much time it needs to draw a frame, support for the presentation time protocol, and other work. Aside from latency improvements, there are Wayland protocol additions for primary selection for allowing middle-click-paste to work plus the output-power-management protocol for better handling display output power management behavior.

libinput 1.16.0

Filed under
Graphics/Benchmarks
Linux

libinput 1.16.0 is now available.

No significant changes since the second RC, so here's slightly polished RC1
announcement text.

This has been a long cycle, mostly because there weren't any huge changes on
the main development branch and a lot of the minor annoyances have found
their way into the 1.15.x releases anyway.

libinput now monitors timestamps of the events vs the current time when
libinput_dispatch() is called by the compositor. Where the difference
*may* result in issues, a (rate-limited) warning is printed to the log.
So you may see messages popping up in the form of
  "event processing lagging behind by XYZms, your system is too slow"
This is a warning only and has no immediate effect. Previously we would only
notice (and warn about) this when it affected an internal timer. Note that
these warnings do not show an issue with libinput, it shows that the the
compositor is not calling libinput_dispatch() quick enough.

The wheel tilt axis source was deprecated. No device ever had the required
udev properties set so we should stop pretending we support this.

Touchpads now support the "flat" acceleration profile. The default remains
unchanged and this needs to be selected in the configuration interface. The
"flat" profile applies a constant factor to movement deltas (1.0 for the
default speed setting).

Events from lid or tablet-mode switches that are known to libinput as being
unreliable are now filtered and no longer passed to the caller.
This prevents callers from receiving those known-bogus events and having to
replicate the same heuristics to identify unreliable devices that libinput
employs internally.

A new "libinput analyze" debugging tool is the entry tool for analysing
various aspects of devices. Right now the only tool is
"libinput analyze per-slot-delta" which can be used to detect pointer jumps
in a libiput record output. This tool used to live elsewhere, it was moved
to libinput so that reporters can easier run this tool, reducing the load on
the maintainers.

The tools have seen a few minor improvements, e.g.
- "libinput record touchpad.yml" does the right thing, no explicit --output
  argument required
- libinput measure touchpad-pressure has been revamped to be a bit more
  obvious
- libinput measure touchpad-size has been added (as replacement for the
  touchpad-edge-detector tool)
- libinput measure fuzz has been fixed to work (again and) slightly more
  reliable

The libinput test suite has been fixed to avoid interference with the
currently running session. Previously it was virtually impossible to work
while the test suite is running - multiple windows would pop up, the screen
would blank regularly, etc.

And of course a collection of fixes, quirks and new bugs.

As usual, see the git shortlog for details.

Diego Abad A (1):
      FIX: typo on building documentation

Peter Hutterer (2):
      test: semi-fix the switch_suspend_with_touchpad test
      libinput 1.16.0

git tag: 1.16.0

Read more

Also: >Libinput 1.16 Released - Ready To Warn You If Your System Is Too Slow

Graphics: MoltenVK, Wayland-Utils 1.0 and XFB

Filed under
Graphics/Benchmarks
  • MoltenVK Update Brings Vulkan To Apple's tvOS

    The MoltenVK update against the Vulkan SDK 1.2.148 now allows tvOS platform support alongside iOS and macOS. Apple's tvOS is the operating system found on the Apple TV hardware over the past decade. Apple tvOS is in turn derived from iOS. For the past several years, tvOS has offered App Store integration for third-party software while now these apps can decide to make use of Vulkan.

  • wayland-utils 1.0.0

    This is first release of wayland-utils which only contains (for now)
    wayland-info, a utility for displaying information about the Wayland
    protocols supported by a Wayland compositor.

    wayland-info is basically a standalone version of weston-info as found
    in weston repository.

  • Wayland-Utils 1.0 Relased As New Utility Package For Wayland Tools

    In addition to the Weston 9.0 Alpha compositor, this week also brought Wayland-Utils 1.0 as the inaugural release for this collection of Wayland utilities/tools.

    Wayland-Utils was started in July after the wayland-info tool was spun out of Weston code for offering a generic Wayland tool. The wayland-info program prints various Wayland protocol details and other compositor-agnostic information. Previously there was the weston-info utility that has now been superseded by the more generic wayland-info tool and also as a standalone package separate from Weston.

  • Mike Blumenkrantz: Primitive Pain

    I’ve talked in the past about XFB, and I’ve talked about queries, but I’ve never spent much time talking about XFB queries.

    That’s going to change.

    XFB is not great, and queries aren’t something I’m too fond of at this point after rewriting the handling so many times, but it was only the other day, while handling streams for XFB3/ARB_gpu_shader5 (humblebrag) that I realized I had been in the infant area of the playground until this moment.

Graphics: Alpha of Wayland's Weston 9.0, Emulating Input Devices In Wayland, Raspberry Pi 4 "V3DV" Vulkan Driver and X.Org/X11 Security

Filed under
Graphics/Benchmarks

  • weston 8.0.91
    This is the alpha release for Weston 9.0.0. This release cycle has been
    pretty quiet, with just a few new features:
    
    
    
    
    - A new kiosk shell allows to display regular desktop apps in an
      always-fullscreen mode
    - Improved testing infrastructure: the test harness has been
      redesigned, DRM tests are now supported, DRM and OpenGL tests are now
      enabled in our CI
    - DRM panel orientation property support
    
    
    
    
    As always, a number of bug fixes are included as well.
    
    
    
    
    Thanks to all contributors!
    
    
    
    
    Full commit history below.
    
  •        

  • Wayland's Weston 9.0 Reaches Alpha

    Weston 9.0 release preparations are getting underway. At least compared to the original Weston 9.0 release plans, this Wayland compositor is running about a month behind those plans but in any case the release is now making its way to reality. 

    On Thursday shortly after the Weston kiosk/full-screen shell was merged, Weston 9.0 Alpha was tagged in getting the release process moving forward. Simor Ser is again serving as release manager. 

  • RFC: libei - emulated input in Wayland compositors
    I've been working on a new approach for allowing emulated input devices in
    Wayland. Or in short - how can we make xdotool and synergy work? And
    eventually replace them.
    
    
    
    
    The proposal I have is a library for Emulated Input, in short libei.
      https://gitlab.freedesktop.org/whot/libei/
    
    
    
    
    libei has two parts, the client side (libei) for applications and
    a server side (libeis) for the compositor. The two libraries communicate
    with each other (how? doesn't matter, it's an implementation detail) to
    negotiate input devices.
    
    
    
    
    The process is roughly:
    - the libei client connects and says "I am org.freedesktop.SomeApplication
      and I want a pointer and a keyboard device"
    - the libeis server says "ok, you can have a pointer device and a keyboard
      device"
    - the libei client says 'move the pointer by 1/1', etc. and the server does
      just that. or not, depending on context.
    
    
    
    
    There are more details, see the README in the repo and the libei.h and
    libeis.h header files that describe the API.
    
    
    
    
    The sticking point here is: emulated input comes via a separate channel.
    The server a) knows it's emulated input, b) knows who it is coming from and
    c) has complete control over the input.
    
    
    
    
    a) is interesting because you can differ between the events internally. The
    API right now is very similar to libinput's events so integrating it into a
    compositor should be trivial.
    
    
    
    
    b) is somewhat handwavy if an application runs outside a sandbox - any
    information will be unreliable. Flatpak gives you an app-id though and
    with that we can (eventually) do things like storing the allow/deny
    decisions of the user in the portal implementation.
    
    
    
    
    c) allows you to e.g. suspend the client when convenient or just ignore
    certain sequences altogether. The two made-up examples are: suspend EI
    during a password prompt, or allow EI from the software yubikey *only*
    during a password prompt.
    
    
    
    
    Now, the next question is: how do they *start* talking to each other?
    libei provides multiple backends for the initial connection negotiation. My
    goal is to have this work with flatpak portals so an application running
    within the sandbox can be restricted accordingly. Alternatives to this could
    be public DBus interfaces, simple fd passing or (as is implemented right
    now) a named unix socket.
    
    
    
    
    The aim is that a client can simply iterate through all of the options until
    finds a connection. Once that's found, the actual code for emulating input is
    always the same so it's trivial to implement a client that works on any
    compositor that supports some backend of libeis.
    The server part only needs to care about the negotiation mechanisms it
    allows, i.e. GNOME will only have dbus/portal, sway will only have... dunno,
    fd exchange maybe?
    
    
    
    
    Next: because we have a separate channel for emulated input we can hook up
    XTEST to use libei to talk to a compositor. I have a PoC implementation for
    weston and Xwayland:
      https://gitlab.freedesktop.org/whot/weston/-/commits/wip/eis
      https://gitlab.freedesktop.org/whot/xserver/-/commits/wip/xwayland-eis
    With that xdotool can move the pointer. Note this is truly the most minimal
    code just to illustrate the point but you can fill in the blanks and do
    things like the compositor preventing XTEST or not, etc.
    
    
    
    
    This is all in very early stages with very little error checking so things
    will probably crash or disconnect unexpectedly. I've tried to document the
    API to make the intentions clear but there are still some very handwavy
    bits.
    
    
    
    
    Do let me know if you have any questions or suggestions please though.
    
    
    
    
    Cheers,
      Peter
    
    
    
    
    
  • LIBEI Yields New Effort For Emulating Input Devices In Wayland

    Red Hat's input expert Peter Hutterer has started writing another library to help the Linux input ecosystem: LIBEI. This new library is focused on offering emulated input device support for Wayland in order to support use-cases like xdotool for automating input events. 

    The LIBEI library is working to support emulated input use-cases on Wayland to offer functionality akin to X11's xdotool automation software or the Synergy software for sharing keyboard/mouse setups between systems. LIBEI consists of a client library for applications and then a server-side library (LIBEIS) for the Wayland compositor integration. These two libraries communicate with each other for negotiating the emulated input events.

  • Alejandro Piñeiro: v3dv status update 2020-07-31

    Pipeline cache objects allow the result of pipeline construction to be reused. Usually (and specifically on our implementation) that means caching compiled shaders. Reuse can be achieved between pipelines creation during the same application run by passing the same pipeline cache object when creating multiple pipelines. Reuse across runs of an application is achieved by retrieving pipeline cache contents in one run of an application, saving the contents, and using them to preinitialize a pipeline cache on a subsequent run.

    Note that it can happens that a pipeline cache would not improve the performance of an application once that it starts to render. This is because application developers are encourage to create all the pipelines in advance, to avoid any hiccup during rendering. On that situation pipeline cache would help to reduce load times. In any case, that is not always avoidable. In that case the pipeline cache would allow to reduce the hiccup, as a cache hit is far faster than a shader recompilation.

    One specific detail about our implementation is that internally we keep a default pipeline cache, used if the user doesn’t provide a pipeline cache when creating a pipeline, and also to cache the custom shaders we use for internal operations. This allowed to simplify our code, discarding some custom caches that had alread implemented.

  • Raspberry Pi 4 "V3DV" Vulkan Driver Begins Tackling MSAA, Other Improvements

    This month the Raspberry Pi Foundation funded "V3DV" open-source Vulkan driver for the Raspberry Pi 4 began being able to run vkQuake. In ending out July, the developers at consulting firm Igalia who are working on this driver for the Raspberry Pi Foundation shared some of their latest driver activity. 

  •         

  • X.Org's Latest Security Woes Are Bugs In LibX11, Xserver

    The X.Org/X11 Server has been hit by many security vulnerabilities over the past decade as security researchers eye more open-source software. Some of these vulnerabilities date back to even the 80's and 90's given how X11 has built up over time. The X.Org Server security was previously characterized as being even worse than it looks while today the latest vulnerabilities have been made public. 

    CVE-2020-14344 is now public and covers multiple integer overflows and signed/unsigned comparison issues within the X Input Method implementation in the libX11 library. These issues can lead to heap corruption when handling malformed messages from an input method. 

Graphics: Wayland's Weston, NIR and AMD

Filed under
Graphics/Benchmarks

           

  • Wayland's Weston Compositor Introduces Kiosk/Fullscreen Shell

    While there is already the Cage kiosk full-screen shell as well as the likes of Ubuntu's Mir Kiosk Shell, Wayland's Weston reference compositor now has its own implementation. 

    Collabora graphics developer Alexandros Frantzis has contributed "kiosk-shell" to Weston, Wayland's official reference compositor. The Kiosk Shell is a full-screen shell for applications making use of the XDG-Shell protocol. 

  •                

  • Mike Blumenkrantz: Debugging

    It’s another hot one, so let’s cool down by checking out a neat bug I came across.

    As I’ve mentioned previously, zink runs a NIR pass to inject a gl_PointSize value into the last vertex processing stage of the pipeline for point draws. 

  •        

  • ACO Radeon Shader Back-End Adds Unit Testing Framework To Help Test Optimizations

    The popular "ACO" shader compiler back-end that recently was promoted to the default shader compiler for Mesa's open-source Radeon Vulkan driver (RADV) has long been testing with shaders and traces while now a proper unit testing framework is being introduced for verifying optimizations are correctly handled, ensuring no regressions, etc. 

    ACO continues on a nice upward trajectory this year with being the default over AMDGPU LLVM for the RADV driver in Mesa 20.2, Valve continuing to fund the developers working on it, RadeonSI OpenGL driver support still being worked on, and various performance optimizations continuing. For helping to keep on that trajectory, today a unit testing framework was merged for ACO. 

Syndicate content