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

- AMDGPU DC Gets More Raven Ridge Improvements, Audio Fixes
Harry Wentland of AMD has sent out the latest batch of patches for the AMDGPU DC display code stack. Fortunately it lightens up the DRM driver by about six thousand lines thanks to removing some unused code.

Besides gutting out a chunk of unused code, the DC code has a few audio fixes (no word yet on supporting newer audio formats with DC), fixes on driver unload, a "bunch" of continued Raven Ridge display updates, and various other code clean-ups.

The list of the 24 latest patches for AMDGPU DC can be found on amd-gfx.

These patches are coming too late to get in DRM-Next for Linux 4.16, thus the first batch now for Linux 4.17.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-More-Raven-Fixes

Como seria mais ou menos previsível, este novo patches reduz o código em 6000 linhas devido ao clean up.

- AMDGPU Firmware Blobs Updated For Video Encode/Decode
The updated firmware files now available via the main linux-firmware.git repository are centered around the video blocks: UVD video decoding, VCE video encode, and the new VCN video encode/decode block with Raven Ridge.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-FW-UVD-VCE-VCN-Update
 
Radeon Linux Graphics Stack, RadeonSI Shaders Update From FOSDEM 2018

Hähnle's presentation won't be too surprising if you are a regular Phoronix reader. If not you really should be reading the site daily for staying up to date with all of the Linux graphics news and more! The milestones talked about include the mainlining of AMDGPU DC, AMDVLK being open-sourced, the new unified AMDGPU-PRO package, OpenGL 4.5 conformance, and zero-day open-source hardware support.
https://www.phoronix.com/scan.php?page=news_item&px=FOSDEM-2018-AMD-Linux

Links para as apresentações do FOSDEM 2018
The AMD Linux Graphics Stack - 2018 Edition
Shaders in RadeonSi Dynamic Linking and NIR
 
34 More Patches Roll Out For AMDGPU DC With Raven Ridge Fixes Plus Color Management

Open-source AMD Linux driver developers have started off the week by posting 34 more patches for the "DC" display code stack that was mainlined in Linux 4.15 and further improved with Linux 4.16. With these latest patches that begin the queue for Linux 4.17 there are yet more AMDGPU DC improvements and in particular Raven Ridge fixes.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-34-More-With-Raven



AMD Ryzen 5 2400G Radeon Vega Linux OpenGL/Vulkan Gaming Benchmarks
https://www.phoronix.com/scan.php?page=article&item=ryzen5-2400g-vega11&num=1
 
Boas notícias para os utilizadores de APU/GPU AMD Radeon, parece ter chegado O momento.

Linux 4.17 To Enable AMDGPU DC By Default For All Supported GPUs
Since the introduction of the AMDGPU DC display code (formerly known as DAL) in Linux 4.15, this modern display stack has just been enabled by default for newer Radeon Vega and Raven Ridge devices. With Linux 4.17 that is changing with AMDGPU DC being enabled by default across the board for supported GPUs.
The AMDGPU DC support goes back to include Polaris, Carrizo, Tonga, Bonaire, and Hawaii.
AMDGPU DC is what allows for atomic mode-setting support, HDMI/DP audio, will allow for open-source mainline FreeSync support, and other modern display features. Up to now on Linux 4.15 and 4.16, the amdgpu.dc=1 kernel command-line argument was needed for turning on the support.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-4.17-Default
 
AMDGPU DC Begins Reworking FreeSync Module
The latest batch of AMDGPU DC display code patches were posted last night on the mailing list. These 32 patches touching around three thousand lines of code have more fixes and also work on the FreeSync module.
Unfortunately though no word on when all of the FreeSync bits will be settled in full for allowing users a pleasant out-of-the-box open-source experience if having a modern Radeon GPU paired with a FreeSync-capable monitor.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-FreeSync-Atomic

Não deixar de notar o comentário do Alex Deucher no fórum

phoronix.png

https://www.phoronix.com/forums/for...working-freesync-module?p=1017102#post1017102
 
Podia ir para o geral de notícias do Linux, mas o crédito a quem o merece ;)

1 December 2017
With two patches sent out today, the AMDGPU scheduler that comes in at a few hundred lines of code would be punted out into a common drivers/gpu/drm/scheduler directory to make it easier for re-use by others and then referring to it as DRM_SCHED as the new Kconfig switch. The code also drops the "amd_" prefixes for the scheduler calls in favor of just the "drm_" moniker.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-Scheduler-Common

1. Etnaviv Now Making Use Of AMDGPU DRM Scheduler, GC7000L Support Coming For Linux 4.18 - 22 March 2018
The open-source driver developers responsible for the reverse-engineered, open-source Vivante GC graphics driver "Etnaviv" have sent in the pull request of their updates for DRM-Next that is of material to be found in the upcoming Linux 4.17 development cycle.

The most notable addition to the Etnaviv Direct Rendering Manager driver for Linux 4.17 is that it's now wired into the DRM GPU scheduler, or rather it's the AMDGPU scheduler that was punted into the common DRM space. I

The Etnaviv DRM driver also has prep work for supporting the latest-generation GC7000L hardware. The GC7000L support is important since that is what's used by the NXP i.MX8 SoC that will be used by the Purism Librem 5 smartphone and other devices.
https://www.phoronix.com/scan.php?page=news_item&px=Etnaviv-Updates-Linux-4.17

2. The Linux-Lima DRM Driver For ARM Mali Hooks Up To The AMDGPU Scheduler - 1 April 2018
Linux-Lima is the ARM Mali driver that's being worked on by Qiang Yu and not to be confused with Luc Verhaegen's retired effort on the original Lima driver project. Linux-Lima continues to be developed out-of-tree and is focused on ARM Mali 400/500 series support, one of several open-source, reverse-engineering efforts now around the various generations of Mali hardware.

Back in February Qiang Yu hooked up the driver to use the AMDGPU scheduler. The Linux-Lima driver continues seeing new code commits every few days and is currently tracking the Linux 4.16 kernel. This driver should work with SoCs like the Exynos4, Sun7i, and Sun8i.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Lima-AMDGPU-Driver

3. Broadcom VC5 Driver Making Good Progress With Using AMDGPU's DRM Scheduler - 10 April 2018
Broadcom's Eric Anholt exploring the use of AMDGPU's DRM scheduler within the in-development Video Core V (VC5) DRM driver. That work has panned out and looks like it will eventually work out for this open-source Broadcom graphics driver.

Eric Anholt has spent the past two weeks wiring up the AMDGPU DRM scheduler now known as DRM_SCHED to the driver, similar to Etnaviv also now using this scheduler code that provides a serial run queue to each client and also easier support for some new features.
https://www.phoronix.com/scan.php?page=news_item&px=VC5-AMDGPU-Sched-Going


:clap:
 
RADV vs. AMDVLK Vulkan Drivers Continue Stiff Performance Battle

For your viewing pleasure today is a fresh look at the AMDVLK versus RADV Vulkan driver performance when testing each of these AMD Vulkan Linux drivers with a Radeon RX 580 Polaris and RX Vega 64 graphics cards. The AMDVLK driver was built from Git master source on 17 April. The RADV driver was obtained from Mesa 18.1-dev built against LLVM 7.0 SVN via the Padoka PPA on 16 April.
https://www.phoronix.com/scan.php?page=article&item=radv-amdvlk-apr2018&num=1

em alguns casos já é elea por ela, mas ainda tem de melhorar bastante.
 
Muita calma nessa hora! Isso vai para aí uma grande confusão.
1º esquece esse esquema, usa o que está no #4 da 1ª página.

Assim muito rápido, a única coisa que precisas de saber, a partir da GCN 1.2 em Linux apenas haverá driver Open Source!

Problema é que teve de ser criado praticamente todo de raíz para suportar novas features e facilitar o desenvolvimento, etc, incluindo um novo Direct Rendering Manager (DRM). Mas o driver em si é composto por vários - vamos-lhe chamar - módulos, ex OpenGL, OpenCL, Vulkan, etc, mas nem todos os módulos estão terminados ou estão em "código aberto", daí que:

- AMDGPU = driver open source
- AMDGPU-Pro = closed source = driver open source + módulos closed source
- Radeon Pro = AMGPU-Pro para as linhas GPU profissionais (certificação de drivers)

em relação ao resto:

OpenGL e Vulkan são API gráficas, o OpenCL é uma API para computação, usando os recursos adicionais além do CPU (CPU + GPU, DSP, etc), neste caso há uma sobreposição disto com o HSA, e com a integração CPU+GPU da AMD nos APU que resulta num outro módulo que também está no driver - AMDKFD, que visava sobretudo simplificar e implementação quer do OpenCL quer de outras linguagens/API de computação.

O ROCm - Radeon Open Compute platform, basicamente reúne tudo, desde compiladores, libraries (tradução?), linguagens, SDK de software relacionado com a parte da computação.

O GPUopen na prática é apenas um portal que reúne quer a parte de computação ROCm quer a parte propriamente gráfica, com os respectivos add-ons, libraries,etc.
Dai que quando acedes ao mesmo está dividido em: Games & CGI e o Professional Compute.

VULKAN, o módulo da AMD é o AMDVLK e só recentemente foi "aberto o código", pelo que OS developers, acho que da Red Hat, resolveram a coisa usando o da Intel (ANV) ligado ao DRM da AMD, daí resultando o RADV, pelo que agora há 2 :D

MESA: basicamente o objectivo é ter as partes comuns dos standards partilhados por todos.
Mesa implements a cross-language, cross-platform (mostly on BSD and Linux distributions), vendor-neutral standard API for interfacing with diverse vendor-specific graphics hardware drivers.
https://en.wikipedia.org/wiki/Mesa_(computer_graphics)

No mesamatrix podes ver todas as extensões (comuns iniciadas pelo GL_ARB do OpenGL), as extensões específicas de cada vendor inciam de forma diferente ex: GL_NV (nvidia), GL_AMD (Amd) e por aí fora ficam dentro dos módulos de cada driver Nvidia, AMD, Intel, etc.
https://mesamatrix.net/

Basicamente qualquer OS developer pode contribuir para as mesmas, e Intel, AMD estão entre os maiores, a que se soma agora a Valve que contratou developers

most active contributor to Mesa this year, it's been Brian Paul, the founder of Mesa 3D and current employee of VMware with being responsible for 8% of the commits so far this year. The next top five are Timothy Arceri, Samuel Pitoiset, Eric Anholt, Dave Airlie, Bas Nieuwenhuizen. It's worth pointing out the second and third most active contributors to Mesa are Timothy and Samuel as part of Valve's Linux GPU driver team where they are primarily working on the RadeonSI and RADV drivers.
When it comes to commits by domain, among companies the top companies to thank are VMware, Intel, Red Hat, and AMD.
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-2018-Q1-Stats


Não sei se esta explicação demasiado rápida resolveu alguma coisa... :wvsore:
 
Pois é, isto não há fome que não dê em fartura. Estou a ver que muito coisa é "software glue" e também há algumas sobreposições e fronteiras kernel / userspace. Isto do HSA tem avançado a passo de caracol...
Obrigado pela explicação!
 
Pá eu acho que a confusão maior é o facto de o Michael usar o termo "driver" para tudo e mais alguma coisa, suporte a OpenGL (driver), suporte a Vulkan (driver), e por aí fora e para quem não está a seguir desde o início fica meio perdido a tentar perceber quantos drivers há, e quais deve instalar, daí ter usado o termo módulos (ou componentes) do Driver.

O HSA não tem avançado a passo de caracol, apenas a AMD tem hardware capaz de suportar, neste momento o suporte apenas está nos APU, mas os mais recentes patches do AMKFD já adicionam suporte a dGPU, além disso apesar de os membros serem praticamente os mesmos, assistiu-se no últimos 2 anos a uma explosão de adesões na categoria Academics, de Universidades/Institutos, depois de ter sido criado um centro regional na China.
No fundo isto é um trabalho de sapo que tem de ser feito para conseguir pôr tudo em ordem 1º.

Já tens algumas empresas a começar a usar o trabalho reunido no ROCm
https://www.gpueater.com/

outras dedicadas a optimização de software de computação até trabalham com tudo
https://streamhpc.com/
 
Última edição:
Para a malta que usa o Kaveri, com drivers opensource, aparentemenre no próximo Mesa 18.2 + AMDGPU já terá mais performance que o Mesa 18 + RadeonSI

Four Years After Launch, AMD Kaveri Sees Huge Performance Boost On Linux
For the purposes of this testing given the render back-end change, I tested the AMD A10-7870K system in three configurations:

- Ubuntu 18.04 LTS out-of-the-box with its Linux 4.15 kernel and Mesa 18.0-rc5. This provides the Radeon DRM driver and RadeonSI supporting OpenGL 4.5.

- The same Ubuntu 18.04 LTS installation with Linux 4.15 and Mesa 18.0 but with booting radeon.cik_support=0 amdgpu.cik_support=1 to use the AMDGPU DRM driver to show how the performance changes just when changing out the kernel Direct Rendering Manager code.

- The same Ubuntu 18.04 LTS installation and again using the AMDGPU DRM driver but upgrading to Mesa 18.2-devel as of Saturday via the Padoka PPA. This latest Mesa Git code has the Kaveri render back-end change when using AMDGPU.
https://www.phoronix.com/scan.php?page=news_item&px=AMDKFD-Linux-4.18-Improvements

NOTA: que ainda não foi lançado o MESA 18.1 e que o Michael para este teste usou a versão 18.2 dev
 
Era algo mais ou menos expectável.

Patches Prep The Merging Of AMDKFD + AMDGPU Linux Drivers
AMDKFD has been a separate driver since originally it supported interfacing with the (pre-GCN) Radeon DRM driver too but these days is only focused on the AMDGPU driver for all GCN hardware driver coverage. AMDKFD is what pairs with the ROCm bits in user-space for providing a quite capable and fully open-source compute/OpenCL stack
https://www.phoronix.com/scan.php?page=news_item&px=Patches-Prep-AMDKFD-AMDGPU

EDIT:

AMDGPU-PRO 18.30 Pro/Open vs. Upstream Mesa OpenGL/Vulkan Radeon Benchmarks

embed.php

https://www.phoronix.com/scan.php?page=article&item=amdgpu-pro-1830&num=1
 
Última edição:
FreeSync quase a chegar ao MESA e por arrasto aos OSS drivers, infelizmente para já apenas para o X, nada de Wayland.

AMD Finally Rolls Out New Linux Patches For Adaptive-Sync / VRR (FreeSync)
There have been open-source FreeSync patches previously, which were once held up by the AMDGPU DAL/DC bits landing and enabled by default. But most recently the mainlining of this FreeSync/Adaptive-Sync/VRR functionality was held up on ensuring their proposed DRM (Direct Rendering Manager) API for handling the DisplayPort/HDMI standards were acceptable to the other driver developers, namely the open-source Intel driver developers.

In case you are late to the party, Adaptive-Sync / VRR are the industry standards now for variable refresh rates to reduce/avoid stuttering, tearing, and/or input lag. Supporting this by the open-source Linux graphics drivers needs bit in the kernel space (DRM) as well as within Mesa, the X.Org DDX driver, and Mesa.
https://www.phoronix.com/scan.php?page=news_item&px=AMD-September-2018-VRR-AS

EDIT: agd5f A.K.A. Alex Deucher:
Once the kernel side lands, the userspace side (ddx, mesa) will as well. The current AMD specific implementation is already included in our packaged drivers. The upstream version will replace the AMD specific version in the packaged drivers once it goes upstream.
https://www.phoronix.com/forums/for...ptive-sync-vrr-freesync?p=1046756#post1046756
 
Última edição:
Back
Topo