Language Selection

English French German Italian Portuguese Spanish

Graphics: Mesa, V3DV, and ROCm

Filed under
Graphics/Benchmarks
  • Mesa 21.1 Will Aim To Be Out By Mid-May - Phoronix

    With Mesa 21.0 released earlier this month following a one month delay, the Mesa 21.1 release calendar has now been published for that next quarterly feature release.

    Mesa 21.1 has been under development since 21.0 was branched off in January and as such a lot of work has already accumulated while there still are a few weeks to build up more feature code. Mesa 21.1 is planned for branching and the first release candidate around 14 April. Following that mid-April branching, weekly release candidates will continue until the official release is ready.

  • Mesa Could Fork Older "Classic" Display Drivers Out To A Separate "Mesa Classic-LTS" Branch - LinuxReviews

    Dylan Baker, release-manager for the Mesa graphics stack used by all the GNU/Linux distributions, is proposing to rid the Mesa of older "classic" display drivers by moving them to a separate "classic-lts" branch. Users of integrated Intel graphics provided by chips prior to Broadwell would have to switch to the new "classic-lts" graphics library to keep their computers working if Mesa goes forward with Bakers proposal.

    [...]

    The story on the Intel side is a bit different. The modern Intel Iris graphics driver can only be used with Broadwell-series hardware or newer. The Intel Haswell was launched in 2013. The integrated graphics hardware on those chips can only be used with the "classic" i965 OpenGL driver. Many people still use Haswell, and even older chips, today. I have a family-member who uses one. That person does not use GNU/Linux, or free software in general, so that persons life would not be affected if Mesa removes support for Haswell-era hardware from the from the main branch. People who do use free software operating systems would have to either switch to the proposed new "classic-lts" Mesa branch or a proprietary operating system like Microsoft Windows.
    Switching to a "classic-lts" Mesa branch may not be that difficult for those who would need to do so - depending on what GNU/Linux distributions decide to do. The "GL Vendor-Neutral Dispatch library" (libglvnd) makes it possible to have several OpenGL libraries installed side-by-side. Distributions could simply ship both the modern Mesa branch and the classic-lts and none of the affected users would notice that their machine happens to be one using "classic-lts".

  • Proposal Raised For Dropping Mesa's Classic OpenGL Drivers From Mainline This Year - Phoronix

    It's been proposed in the past but never acted upon yet but the idea of dropping/retiring Mesa's "classic" OpenGL drivers from the mainline code-base and letting them potentially live on in an "LTS" branch has once again been brought up.

    Mesa developer Dylan Baker has brought up the idea of removing the classic drivers from Mesa master following next quarter's 21.1 release. The Mesa 21.1 branch would then be forked after Mesa 21.1 is EOL'ed to create a "classic-lts" branch. That classic-lts branch would disable the Gallium3D and Vulkan drivers to just focus on these classic drivers. That branch in turn would only see new build and critical bug fixes. Thanks to GLVND, these classic LTS drivers could be installed in parallel along with newer versions of Mesa.

  • Alejandro Piñeiro: Improving v3dv pipeline caching

    After some investigation, we found that the game was calling ClearAttachment twice every frame. The implementation of those ClearAttachments was relying on a full job with a graphics pipeline. On v3dv by default any pipeline is created with a pipeline cache (provided by the user, or a default pipeline). On v3dv (and in general any Vulkan driver) the main cached data are the compiled shaders, so the main objective of the pipeline cache is avoiding full shader re-compilation on compatible pipelines that are used really often. Why was that time spent on linking shaders?

    The issue was that for each pipeline lookup on the pipeline cache we were doing two cache lookups. The first one against a cache with the shaders in NIR, that is the main intermediate representation for shaders in Mesa (more info about intermediate representation here). And then we used those shaders to fill up the key for a second cache lookup, that if succesful, will return the compiled shader on Broadcom (QPU) assembly format.

    The reason of this two-step lookup is that to compile a shader we call the common (for both OpenGL and Vulkan) Broadcom compiler, and we use some data structures that contain info that will affect the compilation (like if blending is enabled). When we implemented the pipeline cache support, for simplicity, we used the same data structures as part of the cache key. But as such keys were filled with info coming from the NIR shaders, those needed to be linked together on the case of the graphics pipelines.

    When we analyzed how to improve it, we realized that in order to identify the compiled shader, we don’t really need the NIR shaders, as the info derived from them are implicit to the SPIR-V shaders provided to create the pipeline. Those NIR shaders are only really needed to compile the shader. The improvement here was using a different data structure as part of the cache key, and replace the two-cache-lookup with a one-cache-lookup. We needed to do some additional changes, as there were parts of the code that assumed that the NIR shaders would be available, but now if possible we are skipping getting them.

  • V3DV Pipeline Caching Work Leads To Greater Raspberry Pi Vulkan Performance

    Alejandro Piñeiro Iglesias of Igalia wrote a new blog post today outlining the V3DV work on pipeline caching to further enhance the performance. By going from a two-cache to one-cache lookup and other improvements, one of the V3DV test cases dropped from taking 11.4 seconds down to 0.8 seconds. (Meanwhile no pipeline caching yielded a 125 second run-time). With some games/software like the Unreal Engine 4 Shooter demo, it meant several FPS gains.

  • Radeon ROCm 4.1 Released - Still Without RDNA GPU Support

    ROCm 4.0 released back in December with "CDNA" GPU support while now ROCm 4.1 has been released as the newest quarterly feature release to this open-source Radeon compute stack focused primarily on HPC/data-center needs.

    ROCm 4.1 delivers on several new features but before anyone asks, no, there still is not any GFX10/RDNA GPU support for either the Radeon RX 5000 or RX 6000 series. The ROCm compute support remains focused on Vega GPUs and CDNA GPUs, the AMD Instinct MI100. There remains full-support-but-not-guaranteed coverage for Polaris and Hawaii GPUs. Those with the newer RDNA consumer GPUs wanting to use the Radeon Open eCosystem stack, you are left waiting still with ROCm 4.1. The ongoing delay in RDNA GPU support for ROCm appears to be due to AMD's focus on getting everything up to par with the CDNA GPU support with forthcoming super-computer deployments and other big ticket HPC customers.

More in Tux Machines

digiKam 7.7.0 is released

After three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release. Read more

Dilution and Misuse of the "Linux" Brand

Samsung, Red Hat to Work on Linux Drivers for Future Tech

The metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world. Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility. Read more

today's howtos

  • How to install go1.19beta on Ubuntu 22.04 – NextGenTips

    In this tutorial, we are going to explore how to install go on Ubuntu 22.04 Golang is an open-source programming language that is easy to learn and use. It is built-in concurrency and has a robust standard library. It is reliable, builds fast, and efficient software that scales fast. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel-type systems enable flexible and modular program constructions. Go compiles quickly to machine code and has the convenience of garbage collection and the power of run-time reflection. In this guide, we are going to learn how to install golang 1.19beta on Ubuntu 22.04. Go 1.19beta1 is not yet released. There is so much work in progress with all the documentation.

  • molecule test: failed to connect to bus in systemd container - openQA bites

    Ansible Molecule is a project to help you test your ansible roles. I’m using molecule for automatically testing the ansible roles of geekoops.

  • How To Install MongoDB on AlmaLinux 9 - idroot

    In this tutorial, we will show you how to install MongoDB on AlmaLinux 9. For those of you who didn’t know, MongoDB is a high-performance, highly scalable document-oriented NoSQL database. Unlike in SQL databases where data is stored in rows and columns inside tables, in MongoDB, data is structured in JSON-like format inside records which are referred to as documents. The open-source attribute of MongoDB as a database software makes it an ideal candidate for almost any database-related project. This article assumes you have at least basic knowledge of Linux, know how to use the shell, and most importantly, you host your site on your own VPS. The installation is quite simple and assumes you are running in the root account, if not you may need to add ‘sudo‘ to the commands to get root privileges. I will show you the step-by-step installation of the MongoDB NoSQL database on AlmaLinux 9. You can follow the same instructions for CentOS and Rocky Linux.

  • An introduction (and how-to) to Plugin Loader for the Steam Deck. - Invidious
  • Self-host a Ghost Blog With Traefik

    Ghost is a very popular open-source content management system. Started as an alternative to WordPress and it went on to become an alternative to Substack by focusing on membership and newsletter. The creators of Ghost offer managed Pro hosting but it may not fit everyone's budget. Alternatively, you can self-host it on your own cloud servers. On Linux handbook, we already have a guide on deploying Ghost with Docker in a reverse proxy setup. Instead of Ngnix reverse proxy, you can also use another software called Traefik with Docker. It is a popular open-source cloud-native application proxy, API Gateway, Edge-router, and more. I use Traefik to secure my websites using an SSL certificate obtained from Let's Encrypt. Once deployed, Traefik can automatically manage your certificates and their renewals. In this tutorial, I'll share the necessary steps for deploying a Ghost blog with Docker and Traefik.