AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver

RADV vs. AMDVLK vs. Radeon Software Vulkan Driver Performance - October 2018 Linux Gaming
The Vulkan driver configurations came down to:

RADV - Built from Mesa 18.3-devel Git as of last week with the LLVM 8.0.0 SVN AMDGPU back-end, the packages available via the Padoka PPA on Ubuntu.

AMDVLK - The latest AMDVLK sources on GitHub as of 1 October for the latest look at this open-source official AMD Vulkan driver.

PRO - The latest Radeon Software 18.30 package using the "PRO" components consisting of the Vulkan driver derived from AMDVLK sources but with AMD's closed-source shader compiler.
For the most part the RADV driver stack is close to -- or at par -- for performing with the official AMDVLK Vulkan driver while being part of Mesa and is what most Linux gamers prefer or find themselves using out-of-the-box. With the PRO Vulkan driver in several cases its proprietary back-end was delivering some performance advantages, but it also ran into compatibility issues running a few of the Linux games tested.
https://www.phoronix.com/scan.php?page=article&item=amdvlk-radv-okt18&num=1

O AMDVLK tem vindo a ganhar tracção e já está com performance comparável ao RADV.
 
- Mesa RadeonSI Lands FreeSync / Adaptive-Sync Support That Pair With Linux 4.21

With the FreeSync support for AMD GPUs having been merged this week into Linux 4.21, the associated user-space patches are landing now for rounding out this AMD Radeon FreeSync / Adaptive-Sync / VRR support as we enter 2019.

Hitting Mesa 19.0-devel today was the DRI3 loader support around the new DRM Adaptive-Sync / Variable Refresh property and enabling the option for the RadeonSI OpenGL driver. At the moment there is no FreeSync / Adaptive-Sync support for RADV Vulkan. Also, we haven't seen any FreeSync/Adaptive-Sync work on the Wayland front at this time.
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-RadeonSI-Lands-FreeSync


- Radeon ROCm 2.0 Officially Out With OpenCL 2.0 Support, TensorFlow 1.12, Vega 48-bit VA
https://www.phoronix.com/scan.php?page=news_item&px=Radeon-ROCm-2.0-Arrives

- Taking Radeon ROCm 2.0 OpenCL For A Benchmarking Test Drive
In cases where ROCm 2.0 is working out nicely, the Radeon OpenCL performance is very strong against the NVIDIA GPUs with their Linux OpenCL driver. Unfortunately though several of the interesting Linux OpenCL test cases were still not behaving well with ROCm 2.0, but hopefully that will improve in subsequent ROCm 2.x releases as we enter 2019. I'm also working on evaluating ROCm 2.0 TensorFlow performance hopefully in the next few days.
https://www.phoronix.com/scan.php?page=article&item=radeon-rocm-20&num=1
 
:n1qshok:

It Turns Out AMDGPU KFD Compute Support Can Work On 64-bit ARM

Up to now the AMDKFD kernel driver needed for running the ROCm user-space has only worked on x86_64 CPUs, but with some simple changes, it turns out this Radeon compute kernel driver can work on 64-bit ARM as well.
Posted by one the AMDKFD patch wrangler at AMD on Wednesday was this patch allowing the "Kernel Fusion Driver" to build on ARM64 (AArch64). The changes were just a few lines to include allowing the kernel Kconfig option to display for ARM64 and then also dealing with a few x86_64-specific lines of code.

Copied on that patch was Mark Nutter, a principal research engineer at Arm, but no comments in the patch to indicate if there was an ulterior motive for getting AMDKFD working on AArch64.
https://www.phoronix.com/scan.php?page=news_item&px=ARM64-AMDKFD-HSA-Compute

hmmm.... com que então suporte OpenCL 2.0 em CPU ARM :coolshad:
 
AMDVLK 2019.Q1.1 Radeon Vulkan Driver Build Now Available For Ubuntu

Based upon that source code state from yesterday, an Ubuntu Debian package is now available of just the Vulkan driver and validated for at least 16.04/18.04 installations but should end up working too for e.g. 18.10. The release tag also mentions that these fixes have an optimization for fully overwritten resolves and a performance regression fix for The Talos Principle, addressing a potential access violation, and multi-process failure.
https://www.phoronix.com/scan.php?page=news_item&px=AMDVLK-2019.Q1.1-Driver

para quem usa Debian/Ubuntu já pode usar o driver open source Vulkan da AMD (AMDVLK) ao invés do actualmente disponível RADV (também open source mas baseado no ANV da Intel e mantido pelo Bas New qq coisa)
 
Mesa 19.0 RADV vs. AMDVLK 2019.Q1.2 vs. Radeon Software 18.50 Linux Vulkan Performance
The performance between the open-source Mesa-based RADV driver and the official AMD driver options of AMDVLK (open-source, built against LLVM) and Radeon Software PRO (similar to AMDVLK, but still using the proprietary compiler for now) remains quite mixed. In some titles the Radeon Software Vulkan driver still has its advantages particularly for Vega, but it's to a lesser extent these days compared to months ago when it often had some pronounced leads thanks to its quicker ramping up of Vega support. With Mesa 19.0 built against the AMDGPU LLVM 8.0 back-end, the RADV performance is quite good and for newer Feral titles as well as Steam Play titles with DXVK is often leading or at similar to the AMD driver.
https://www.phoronix.com/scan.php?page=article&item=amdvlk-2019q12-mesa19&num=1
 
Não sei se é o melhor sítio para perguntar isto mas cá vai.
Estava a pensar em comprar um computador ara o trabalho com Ryzen 2400G e usá-lo com Linux (Manjaro ou eventualmente Mint).
Este APU é bem suportado? Há problemas de compatibilidade?
Já li que houve alguns problemas com este CPU e também já li que já estava estável, mas gostava de ter a certeza antes de comprar.
 
Não sei se é o melhor sítio para perguntar isto mas cá vai.
Estava a pensar em comprar um computador ara o trabalho com Ryzen 2400G e usá-lo com Linux (Manjaro ou eventualmente Mint).
Este APU é bem suportado? Há problemas de compatibilidade?
Já li que houve alguns problemas com este CPU e também já li que já estava estável, mas gostava de ter a certeza antes de comprar.

Existem algumas instalações de sucesso, no Manjaro. Dá uma vista de olhos no forum oficial. Aqui por exemplo https://forum.manjaro.org/t/manjaro-ryzen-drivers-compatibility/65124
 
A AMD com o lançamento da VEGA VII vai abandonar o Powerplay que será entretanto substituído

"The powerplay driver will be retired. The final version is for vega20 with SMU11. However, the future asic will use the new swSMU framework to implement as well. Here is the first version of new sw smu driver that is basing on vega20...We would like to do re-arch for linux power codes to use a new sw SMU ip block for future asics. We hope to write a simple and readable framework for Linux."
https://www.phoronix.com/scan.php?page=news_item&px=AMD-New-SW-SMU-Driver-Future


@MAntunes à partida a maioria dos relatos diz que os problemas foram resolvidos com o kernel 4.18, portanto é ver qual o kernel usado e eventualmente fazer o upgrade quer do kernel quer do Mesa.
https://askubuntu.com/questions/1070956/how-well-do-amd-raven-ridge-apus-work-with-linux-now
 
Alguém na Valve tem tido tempo livre :biglaugh:

agora além do shader compiler proprietário (AMDGPU Pro) e do "opensource" AMDGPU LLVM a Valve criou o ACO, especificamente tendo como o objectivo... JOGOS.


Help us test ACO, a new Mesa shader compiler for AMD graphics!

the foundation for the Valve open-source graphics group. By leveraging the open development model of the Mesa driver codebase, we were able to provide direct support for Steam and its functionality to Intel and AMD graphics users.
The AMD OpenGL and Vulkan drivers currently use a shader compiler that is part of the upstream LLVM project. That project is massive, and has many different goals, with online compilation of game shaders only being one of them. That can result in development tradeoffs, where improving gaming-specific functionality is harder than it otherwise would, or where gaming-specific features would often accidentally get broken by LLVM developers working on other things. In particular, shader compilation speed is one such example: it's not really a critical factor in most other scenarios, just a nice-to-have. But for gaming, compile time is critical, and slow shader compilation can result in near-unplayable stutter.
To answer that question, we started working on ACO, a new Mesa shader compiler for AMD hardware[github.com]. Its main two goals are best-possible code generation for game shaders, and fastest-possible compilation speed. Starting with radv, we initially got the shaders for a single game to compile and render properly, then worked through the bringup of additional games.
Right now, ACO only handles pixel and compute shader stages. When the rest of the stages are implemented, we expect the compile times will be reduced even further.
https://steamcommunity.com/games/221410/announcements/detail/1602634609636894200

- ACO testing instructions

Benchmarks of 2019-06-14 to 2019-06-17
OS: Fedora 30
uname -r: 5.1.7-300.fc30.x86_64
CPU: Intel® Core™ i7-6700K CPU @ 4.00GHz × 8, 15.6 GiB of RAM
gpu: Vega 64
run in 4K and use highest settings

software versions:
LLVM rL363268
RADV/ACO a092f01be8a (based on Mesa c58dff753c2)
RADV/LLVM c58dff753c2
AMDVLK 2019.Q2.5
AMDGPU-PRO 19.10-785425
Proton 4.2-7
gpu: Vega 64
https://gist.github.com/pendingchaos/aba1e4c238cf039d17089f29a8c6aa63


- Valve Has Been Developing A New Mesa Vulkan Shader Compiler For Radeon

- Valve are asking for help testing "ACO", a new Mesa shader compiler for AMD graphics
 
It Looks Like HDMI FreeSync/VRR For Linux + Wayland Support Will Eventually Come For AMD
AMD provided an update on their Linux FreeSync/Adaptive-Sync support at this week's X.Org Developers Conference event in Montreal. There's good news both for HDMI and Wayland Linux users with Radeon graphics.
Harry Wentland explained that on Windows, AMD uses a proprietary AMD-developed protocol for enabling FreeSync on HDMI. Obviously that won't fly for the open-source AMDGPU kernel driver. But as for the formal HDMI Variable Rate Refresh (VRR) support, they note it's "pending" but held up by a HDMI VRR conformance test suite being released. So hopefully once that CTS is available, HDMI VRR will be flipped on for Linux users wishing to enjoy Adaptive-Sync/VRR functionality for HDMI displays.
https://www.phoronix.com/scan.php?page=news_item&px=AMD-FreeSync-2019-Update
 
AMD Radeon Open-Source Linux GPU Driver Performance: 2020 vs. 2021

For those wondering what the cumulative gain was for 2021 from all these AMD graphics driver changes, here are some end-of-year 2020 vs. 2021 benchmarks across a number of different Linux games while testing on Vega, Navi, and Navi 2 graphics cards.
- Ubuntu 20.10 with Linux 5.9 and Mesa 20.2 for looking at the state of the graphics driver support from late 2020 as shipped by that popular Linux distribution release.

- Ubuntu 21.10 as the current stable release with Linux 5.13 and Mesa 21.2. Basically a direct year-over-year look for the graphics performance on Ubuntu Linux.

- Ubuntu 21.10 but shifting to Linux 5.16 Git and Mesa 22.0-devel from the Oibaf PPA as of the start of the new year for the very bleeding-edge, development code for where the open-source AMD Linux graphics driver performance sits today on that very rich driver stack.

Screenshot-2022-01-07-at-20-18-58-AMD-Radeon-Open-Source-Linux-GPU-Driver-Performance-2020-vs-2021.png

If taking the geometric mean of all the graphics benchmarks carried out for this article, here are where things stand for late 2020 against the end of 2021. The Radeon RX 6800 XT uplift was obviously most impressive with being the latest-generation GPU and saw around 13% better performance made over the course of the past year. The Vega-based Radeon VII performance was up by about 7% going from Ubuntu 20.10 to 21.10 but did regress slightly with the newer Mesa/kernel but at least still ahead of where it was one year ago. The prior-generation RX 5700 XT meanwhile ended the year about 7% faster than where it was in late 2020.
https://www.phoronix.com/scan.php?page=article&item=radeon-2020-2021&num=1
 
:n1qshok:

A surpresa...

HDMI Forum Rejects Open-Source HDMI 2.1 Driver Support Sought By AMD​

For three years there has been a bug report around 4K@120Hz being unavailable via HDMI 2.1 on the AMD Linux driver. Similarly, there have been bug reports like 5K @ 240Hz not possible either with the AMD graphics driver on Linux.
AMD Linux engineer Alex Deucher commented on the ticket:
"The HDMI Forum has rejected our proposal unfortunately. At this time an open source HDMI 2.1 implementation is not possible without running afoul of the HDMI Forum requirements."
Update for added context [20:30 EST]: Further insult to the injury is also that it sounds like AMD spent months of engineering time prototyping code for showing HDMI 2.1+ features within their internal open-source AMDGPU codebase to provide for review to the HDMI Forum. If that never sees the light of day now, it's all a largely wasted effort of significant resources.
https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected
 
Back
Topo