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

AMD Sends Out Patches For New AMDGPU DAL Display Driver, Adds 93k Lines Of Code

AMD's new "DAL" display driver has been posted for review as the new display component to the AMDGPU kernel DRM driver.

This DAL driver supports AMD's Carrizo, Tonga, and Fiji graphics processors atop the AMDGPU kernel driver. This is the driver they will use moving forward for adding new display features to the AMDGPU driver.
http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DAL-Patches-Published

e que pelo "tamanho" levou a críticas de vários developers, mas o Bridgman e o Deucher já tinham vindo explicar no fórum que o objectivo do lançamento não era que isto fosse logo integrado, mas sim para permitir a revisão do mesmo, entretanto um developer da AMD da já veio dar pormenores adicionais

AMD's Harry Wentland described the architecture a bit more. Here's the main part of his message:
The goal with DAL is to provide a unified, full featured display stack to service all of our Linux offerings. This driver will have to support our full feature set beyond what's supported by amdgpu, e.g.
- synchronzied timings across different displays
- freesync
- solid support of 6 displays in any configuration (HDMI, DVI, DP, DP MST, etc)
- solid support of 4k at 60 timings on APUs
- power features, such as
- clock-accurate bandwidth formulas
- improved interaction with powerplay to maximize power savings
- Improved audio and other infoframe related features
- Improved stability with powerplay since display hw is involved in the SMC hw interactions and improper programming sequences can lead to GPU hangs, etc.

The current amdgpu display stack grew somewhat organically and as such is not well suited to handling all of the hardware dependencies involved especially in areas like audio. The drm abstractions used by the old code map less and less well to new hw pipelines. Atomic helps, but if we are going to convert, it seemed like a good time to start fresh.
http://phoronix.com/scan.php?page=news_item&px=AMD-FreeSync-DAL-Plans


não sei porquê, mas o link da mensagem (do dev da AMD) não funciona, o Michael depois no final escreve

He also explained more with their reasoning for some of the code abstraction, how their display core doesn't always map well to the DRM interfaces, the DAL internal abstractions match what is used by the AMD drivers on other operating systems, and how they can further trim this ~93k lines of code (there's a lot of blank lines and code comments).
 
Já vi teorias que essa monstrosidade é em boa parte copy-pasta da Catalyst, mas tenho duvidas visto que não acho que a Catalyst suporte boa parte disso. Pelo mentos free-sync não suportava.
Não sei até que ponto será isso um patch exagerado, até que ponto será um tamanho justo para a funcionalidade, mas também há pelos vistos muita linha em branco e comentada.

Espero que eles fiquem competitivos e atropelem a Nvidia nos proximos anos, já estou farto das drivers da Nvidia, ainda para mais com a bronca que o GLVND está a dar nas 361.28.
 
Quase, quase...

Trying The New AMD GPU-PRO Linux Driver On Ubuntu With Vulkan, OpenCL & OpenGL

On Friday night to much surprise, AMD published the beta version of their new hybrid Linux driver stack with Vulkan support alongside OpenCL, OpenGL, and VDPAU support. Here's some more details from my initial testing of this new driver that AMD is currently calling the Radeon Software AMD GPU-PRO Beta Driver for Linux.
...
AMD's John Bridgman explains it as, "three closed-source components running on top of slightly tweaked copies of open source kernel driver, X driver, libdrm and multimedia drivers." It's the mix of open and closed-source AMD Linux driver components while at the center of it is the open-source AMDGPU kernel DRM driver and the main binary blobs are the OpenGL and Vulkan implementations in user-space.
http://www.phoronix.com/scan.php?page=article&item=amd-gpu-pro&num=1


bridgman
AMD Linux
It will, although it probably doesn't do it today. This is just an early preview to get the Vulkan driver out in public. It was going to be an internal-only release for testing out the production tools/processes for the hybrid driver but given the timing of the Vulkan NDA lift we decided to make it a public preview release instead.
 
Tasks to be completed for 4.7:
- Remove (malloc/free/sleep/delay/etc.) wrappers for building DAL in
userspace (done)
- Switch to using Linux i2c subsystem (done)
- Switch to using Linux drm aux interface (in progress)
- Convert cursors to planes API (in progress)
- Switch to native drm EDID fetching (in progress)

Tasks post 4.7 (we will attempt to fix these sooner as time permits):
- Using common Linux infoframe infrastructure
- Migrating to common logging infrastructure
- Refactoring DC

Current DAL status:
- DCE8 Support (Hawaii, Bonaire)
- DCE10 Support (Fiji, Tonga)
- DCE11 Support (CZ, ST)
- DP support (SST, MST, Audio)
- HDMI Support
- HDMI 2.0 Support (on supported asics)
- DVI Support
- Full integration with power management
- Atomic KMS support
- Solid 4K at 60 Support
https://lists.freedesktop.org/archives/dri-devel/2016-March/103398.html
 
Grande salto da AMD no suporte dos seus GPUs em Linux. Está a melhorar muito rápidamente e está a fazer o melhor trabalho das 3 grandes em suporte open-source. Daqui a 6 ou 9 meses vai estar num estado espectacular.
 
Pena que se a AMD "falir" (for adquirida) isto será tudo em vão.
Espero tanto que os Zen como as Polaris saiam competitivos e a tempo de salvar a AMD.

Dos potenciais aquisitores que já foram referidos nenhum consegue ser tão FOSS friendly como a AMD está a ser.
Se a AMD como conhecemos desaparecer tão cedo como isso não voltamos a ver tanto suporte por parte outro qualquer vendedor.
 
Early Radeon Vulkan Windows vs. AMDGPU PRO Linux Benchmarks

Intel Xeon E3-1280 v5 Skylake box with MSI C236A Workstation motherboard, 16GB of DDR4-2133MHz memory, and 120GB Samsung 850 SSD). Radeon Software Crimson Edition 16.4.1 was in use on the Windows side while the inaugural AMD GPU-PRO stack with Vulkan support was at play on Ubuntu 16.04 x86_64.

mr3cra.jpg

http://phoronix.com/scan.php?page=news_item&px=Radeon-VLK-Windows-Linux

Tendo em conta o resultado, sobretudo nas "Tonga" (285) e "Fiji" (Fury), os resultados prometem, até porque supostamente esta ainda não é a versão final do driver e ainda deve haver mais updates.
 
A driver RadeonSI já atingiu o OpenGL 4.3!

As drivers open-source da AMD deram um salto de gigante neste último mês e com o tempo que falta até á saida da Mesa 11.3 (agora Mesa 12 porque atingiram uma nova versão de OpenGL) pode ser que até consigam alcançar OpenGL 4.4.
Em breve vão poder focar-se só em bugfixes e melhorar performance.
 
Afinal parece que a AMD sempre vai adicionar as GCN 1.0 ao AMDGPU, apesar de poder não vir incialmente com o lançamento do AMDGPU.

AMD Soon Might Have Out AMDGPU Support For The Original GCN GPUs
A Phoronix reader pointed out this comment made two weeks ago by AMD's John Bridgman. When asked about the GCN 1.0 / SI support for the AMDGPU kernel driver, he wrote, "SI support in amdgpu is making pretty good progress, hoping to get the first public code out in the next couple of weeks. Once we have accumulated some test coverage on the CI & SI support and fixed enough bugs that it seems like a decent replacement for radeon upstream we will work with the upstream maintainer to do some organized public testing then enable it by default (disabling radeon for the same chips we enable on amdgpu)."
http://phoronix.com/scan.php?page=news_item&px=AMD-SI-Might-Soon-Get-AMDGPU
 
AMD GPU-PRO Beta Driver – Linux® for Vulkan™ Version 16.20 for Ubuntu 16.04

Highlights
  • Supported APIs:
    • OpenGL 4.5 and GLX 1.4
    • OpenCL 1.2
    • Vulkan 1.0
    • VDPAU
    • DOTA 2 Game support (Vulkan™ enabled)
  • Basic display features
  • Basic power management features
  • KMS (Kernel Mode Setting) and ADF (Atomic Display Framework) support
  • GPL compliant kernel module
  • Install script and Debian packages for Ubuntu 16.04
http://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Beta-Driver-for-Vulkan-Release-Notes.aspx

ainda é uma beta e com limitações, apenas para os chips "Tonga" (285 e 380/X) e "Fiji" (Fury/X e Nano), mas desta feita já suportado pelo Ubuntu 16.04.
 
Alguns benches usando a nova versão do driver híbrido AMDGPU-PRO 16.20.3 Beta 2

AMDGPU-PRO Beta 2 vs. Mesa 11.3 + Linux 4.6: Very Competitive For Linux Gamers

hybrid driver stack for Linux that makes use of the AMDGPU open-source kernel DRM driver with the closed-source OpenGL driver derived from Catalyst / Radeon Software....
...
...the Mesa 11.3-devel and Linux 4.6 open-source RadeonSI Gallium3D driver stack as of last week was compared to the new AMDGPU-PRO Beta 2 driver on Ubuntu 16.04.
http://www.phoronix.com/scan.php?page=article&item=amd-probeta2-mesa113&num=1


e como a nova versão já vinha com o suporte ao Vulkan e DOTA 2


NVIDIA vs. AMD OpenGL & Vulkan Benchmarks With Valve's Dota 2

using the new AMDGPU-PRO 16.20.3 (Beta 2) driver that AMD released last week while explicitly mentioning support for Dota 2 on Vulkan. For the NVIDIA driver tests, the NVIDIA 367.18 beta driver was used as the latest publicly available NVIDIA Linux driver.
http://www.phoronix.com/scan.php?page=article&item=dota-2-vulkan&num=1


De um russo (acho eu) que também testou o AMDGPU vs AMDGPU-PRO neste caso numa HD 7790 (GCN 1.1 "Bonaire" = 260/X e 360)

Intel i5 3330 4C\3Ghz
Radeon hd 7790
amdgpu – openSUSE 42.1 kernel 4.6\Mesa-git+extra patches(tess,PBO) \ llvm-3.9 git
amdgpu-pro – Ubuntu 16.04 kernel 4.4\amdgpu-pro 16.20.3

2z8n40n.png

http://www.gearsongallium.com/?p=3194


2nb7cxg.png

http://www.gearsongallium.com/?p=3198

vpk9ac.png

http://www.gearsongallium.com/?p=3200

2n8wot5.png

http://www.gearsongallium.com/?p=3189

Nos testes de ambos os sites há regressões, a AMD está a tentar identificar a origem das mesmas.
 
Dos potenciais aquisitores que já foram referidos nenhum consegue ser tão FOSS friendly como a AMD está a ser.

Acho que partes de uma permissa errada; Tens o mercado geral dos PC's a cair a pique, e neste momento a quota de mercado de chromebooks como dispositivo primário nos EUA já passou a Apple. Embora eu nao considere o Chromebook como um 'desktop' e o veja mais como um browser a esteroides, tudo isto tem impacto.

Há 2 ou 3 anos (agora nao consigo precisar) a NVIDIA perdeu um negocio de perto de 2 mil milhoes de $US devido à intel oferecer melhor suporte em Linux e o mesmo funcionar out of the box.

Nao te esqueças que sao fabricantes de hardware e cada vez mais, se nao suportarem o sistema que vai correr nao vao ter vendas. Tens um grande exemplo (ainda que fechado) da AMD: todas as PS4 correm hardware AMD em cima de BSD :)

O grande problema desta coisa toda continua a ser a porcaria do licenciamento GPLv2 e LGPL. Enquanto todos parecem adorar essa ditadura de esquerda, eu continuo a acreditar que a verdadeira liberdade está em licenças MIT/BSD.

Basta ver a quantidade de BSD's que andam por aí a pontapé: Mac's, PS4, etc.
 
Desculpem a "duda", mas em relação a esta questão das licenças, qual é o problema da LGPL? A GPL entendo, mas supostamente a LGPL é para bibliotecas e só limita a inclusão do codigo fonte sob a licença, não a utilização da mesma.
A minha interpretação está errada ou existe outro problema que não estou a a ver?
 
Acho que partes de uma permissa errada; Tens o mercado geral dos PC's a cair a pique, e neste momento a quota de mercado de chromebooks como dispositivo primário nos EUA já passou a Apple. Embora eu nao considere o Chromebook como um 'desktop' e o veja mais como um browser a esteroides, tudo isto tem impacto.

Há 2 ou 3 anos (agora nao consigo precisar) a NVIDIA perdeu um negocio de perto de 2 mil milhoes de $US devido à intel oferecer melhor suporte em Linux e o mesmo funcionar out of the box.

Nao te esqueças que sao fabricantes de hardware e cada vez mais, se nao suportarem o sistema que vai correr nao vao ter vendas. Tens um grande exemplo (ainda que fechado) da AMD: todas as PS4 correm hardware AMD em cima de BSD :)

O grande problema desta coisa toda continua a ser a porcaria do licenciamento GPLv2 e LGPL. Enquanto todos parecem adorar essa ditadura de esquerda, eu continuo a acreditar que a verdadeira liberdade está em licenças MIT/BSD.

Basta ver a quantidade de BSD's que andam por aí a pontapé: Mac's, PS4, etc.
Não te referes a isto: http://www.phoronix.com/scan.php?page=news_item&px=MTEyNTE ?

Sim, tens a tua razão. O pessoal do HPC quer o melhor e mais eficiente :)

Quanto ás licensas cada um com a sua ideia. Eu sou pró-GPL. Tendo a escolher é a esse genero de licensas que perfiro.
Com MIT's/BSD's muito mais facilmente há parasitas (Sony) que pegam em softwares feitos por uma comunidade (BSD), os quais melhoram sem partilhar as alterações e acabam a utilizar para fins comerciais.
Se já com GPL empresas como a Google conseguem usar e abusar dos softwares quanto mais se fosse MIT/BSD. É que provavelmente nunca terias visto o codígo fonte do Android.
Para não falar que sem GPL nada proibe de se anexar FOSS a blobs. Dai também muitas das controvérsias da NVidia.

Essa preocupação recentemente voltou a sugir em torno deste projeto. http://www.redox-os.org/
Se hipotéticamente seguir em frente e tiver sucesso (for eficiênte e tiver o seu mercado), é garantido que vai ser vitima de parasitas.
 
Dificilmente a AMD é adquirida como um todo. A licença x86 não é transmissível. Podem vender a divisão de gráficas, mas nesta altura não estou a ver isso a acontecer.

Até agora fugia de AMD o mais possível. Sempre que tive ATI/AMD em gráficas tive problemas. Mas estou a gostar de ver o que a AMD tem feito nos últimos tempos. Estão de parabéns.

Quanto a licenças, no geral não tenho grande opinião, mas tira-me do sério quando duas licenças open source são incompatíveis uma com a outra. Muitas vezes não passa de um jogo de palavras.
 
Quanto ás licensas cada um com a sua ideia. Eu sou pró-GPL. Tendo a escolher é a esse genero de licensas que perfiro.

Eu pessoalmente o que faço e quero publicar vai em MIT precisamente para que quem quiser possa utilizar como quiser e sem restrições.

Com MIT's/BSD's muito mais facilmente há parasitas (Sony) que pegam em softwares feitos por uma comunidade (BSD), os quais melhoram sem partilhar as alterações e acabam a utilizar para fins comerciais.

Não propriamente, a história nao é bem assim. Quer a Sony quer a Apple tem contribuições muito importantes para comunidade que usas diaramente sem sequer saberes. A questao nao é se sao ou nao parasitas (e tens casos mais interessantes como o hack que a sony sofreu expor que eles pirateavam o software de DRM com que protegiam algumas cenas deles).

A questão aqui é que com uma licença verdadeiramente livre, alguem conseguiu pegar numa porcaria de um micro kernel e por aquilo a funcionar a 100% no hardware, e isto nao existe em Linux no mundo dos Desktops. Uma PS4 liga com resoluçao nativa e nao existe flickering. Nenhum driver proprietário suporta KMS, nunca te perguntas-te porque? Por causa do licenciamento.... Se a licença fosse mais permissiva tinhas KMS com qualquer driver...

O que queria expor era isto, o impacto que uma licença tem na usabilidade de algo.

Se já com GPL empresas como a Google conseguem usar e abusar dos softwares quanto mais se fosse MIT/BSD. É que provavelmente nunca terias visto o codígo fonte do Android.

Nunca vi, nem quero ver porque nao tenho muito interesse nisso. De qualquer forma o Google também nao é o santo que pintas, e o moto/mantra deles no inicio (don't be evil) é uma boa banhada. E sim ainda sou tempo pré-google. O android é uma ferramenta de data mining, nada mais.

Para não falar que sem GPL nada proibe de se anexar FOSS a blobs. Dai também muitas das controvérsias da NVidia.

Confusao da tua parte, as distribuiçoes linux é que nao permitem distribuir blobs/binarios que nao tenham sido criados por eles. Isto levou até a alguns problemas interessantes como o caso do 'maven' e do 'ant' que para fazerem build precisam de uma versao anterior. Fazer um build limpo/bootstrap sem um binario pré existente é impossivel. Isto levou a criaçao da piada:

"Qual é a diferença entre o maven e o ant?" - "Os developers do ant pediram desculpa."
 
Back
Topo