Graphics: Mesa, V3DV, and ROCm

-
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.
-

- Login or register to post comments
Printer-friendly version- 2890 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
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.
|
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.
|
today's howtos
|








.svg_.png)
Content (where original) is available under CC-BY-SA, copyrighted by original author/s.

Recent comments
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago