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

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).
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).
Sim, já vi que a Sony contribuiu com alguns patches para o FreeBSD, nada do outro mundo para uma empresa daquela dimensão.
E financeiramente também não é famosa: https://www.freebsdfoundation.org/donors/
Para a empresa que detém a consola com maior sucesso do mundo fica muito a dever, eu chamo isso de parasitar, lucrar milhares de milhões com o trabalho alheio e nem um milhão contribuir de volta.
A Apple sim, já se nota mais algum empenho: https://www.apple.com/opensource/

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...
Eu vejo a liberdade das MIT/BSD como a liberdade do domínio publico, apenas obrigam a que o copyright se preserve.
GPL como a obrigação de passar a liberdade. Sim, em Português falando as MIT/BSD conferem mais liberdade ao utilizador, mas não o fazem retribuir a liberdade que recebeu.

Sim, a Sony teve a liberdade de atirar com blobs no FreeBSD e ficou a funcionar a 100%, mas ao mesmo tempo teve 0 incentivo para usar drivers open como esta AMDGPU e não teve de retribuir os melhoramentos que fez.

Como este tópico debate, a própria AMD está dedicada ao FOSS, qual seria o problema da Sony em fazer o mesmo se utilizam hardware AMD?
O quê é que isso tem de bom? Ajuda a comunidade? Ajuda-os a eles? Acho que nem isso...
Mas pensando bem, esta Sony é a mesma Sony que caça judicialmente utilizadores que tratam as consolas com compram como deles, nem sei porquê é que isso me admira. Já que somos tão livres porquê é que insistem em não nos deixar arrancar outro SO na playstation?

O KMS está dependente de código ser linkado ao kernel, não atuar como um módulo, ser parte do kernel.
Qual seria a solução ideal? Permitir que as NVidias, ARMs, Imaginations, Qualcoms e quem mais queira atire os blobs que bem entendam para dentro do kernel?
Quem garante o que está dentro dos blobs? E se lá estiver um backdoor?
Dizes que licenças permissivas são liberdade, mas então e a liberdade do utilizador saber o que foi anexado ao núcleo do seu SO, aquela parte que consegue fazer o que bem quiser com o computador?

Ai já optas por conferir liberdade ás empresas ou aos utilizadores, e enquanto que nenhum dos dois grupos é particularmente sábio como um todo, o primeiro tende a fazer muita asneirada por interesse comerciais.

Ainda assim usabilidade e ética não tem nada a ver uma coisa com a outra.
A diferença de usabilidade neste caso é principalmente que um diz:
- "Se queres utilizar o que fiz, força, mas retribui com o que fizeres"
e o outro:
- "Não quero saber, faz o que quiseres, guarda, dá de comer ao cão, não me ralo minimamente, apenas deixa o meu nome ai"
Nunca vi, nem quero ver porque nao tenho muito interesse nisso. De qualquer forma o Google também nao é o santo que pintas
Mas se quiseres ver o que faz o TEU telemóvel és livre de o fazer, o código anda por ai.
Não pintei a google como santa, pelo contrário interpretaste mal. O android é praticamente um walled garden, e o GPL não proibiu que isso acontecesse. Continua-se a poder ver o código e fazer forks, mas a partir do momento em que se quebre a compatibilidade com os APKs, ou nem tanto, se perca o acesso à PlayStore perde a maior parte da relevância. Eles conseguiram isolar o ecossistema deles mesmo estando a utilizar a licença que mais força a partilha

Desculpa lá se o que escrevo aparenta estar em tom de rant, apenas estou a tentar não me extender demasiado e ir direito ao tema sem fugir demasiado ao tópico :p
 
Sim, já vi que a Sony contribuiu com alguns patches para o FreeBSD, nada do outro mundo para uma empresa daquela dimensão.
Eu tento ser sempre abrangente e nao quero de forma alguma por aqui uma lista interminavel de outras contribuições da sony, portanto vou-me conter apenas a alguns pontos tocados previamente. Contribuições da Sony no mundo Android:
  1. AOSP mod para funcionar correctamente nos Xperia (existem montes de contribuições da Sony);
  2. DASH, Dynamic Android Sensor HAL (Android);
  3. LiveTouch, biblioteca;
  4. Binds para o GWT maps;
Isto só no campo dos Androids. As contribuições em dinheiro continuam a serem superiores às da ANSOL ou outras empresas Portuguesas que se tentam afirmar como open source. Por outro lado a Sony é um dos players mais fortes dentro do mundo do open hardware?!


Eu vejo a liberdade das MIT/BSD como a liberdade do domínio publico, apenas obrigam a que o copyright se preserve.
GPL como a obrigação de passar a liberdade. Sim, em Português falando as MIT/BSD conferem mais liberdade ao utilizador, mas não o fazem retribuir a liberdade que recebeu.

Curiosamente, a utilização da GPL está a cair em deterimento de outras licenças mais livres. Entre 2009 e 2016 a GPL perdeu perdeu perto de 20 pontos percentuais face a outras licenças mais permissivas. Inclusivé, a ineficiencia da GPL é clara devido à necessidade de muitos projectos terem que por licenciamento duplo, GPL + LGPL. Como te disse é uma preferencia pessoal da minha parte.



Sim, a Sony teve a liberdade de atirar com blobs no FreeBSD e ficou a funcionar a 100%, mas ao mesmo tempo teve 0 incentivo para usar drivers open como esta AMDGPU e não teve de retribuir os melhoramentos que fez.

É ao contrário. Quem desenvolve os drivers é a AMD, pelo que na realidade ao utilizar um micro kernel BSD, o licenciamento do mesmo nao interfere e permite que a AMD continue a manter o seu driver para o hardware em questão. Nao é a sony que desenvolve os drivers.

A AMD é um fornecedor, nao tem que ter incentivos, tem que responder ao que lhe é solicitado. Ou entrega valor ou nao entra no negocio, e para entregar valor tem que ter as coisas a funcionar de acordo com o que é esperado porque no final o sucesso de uma plataforma PS4 ou equivalente é ditado pela performance e pela satisfaçao dos consumidores.



Como este tópico debate, a própria AMD está dedicada ao FOSS, qual seria o problema da Sony em fazer o mesmo se utilizam hardware AMD?

A AMD assim como a Intel e outras empresas estão dedicadas porque é a nova trend da industria, e como dependem da venda de hardware para sobreviverem, ou respondem ou nao morrem. Isto é uma questao de exigencia de mercados e nao ideologica.

Sabes, há uma coisa no mundo real muito diferente das universidades e micro-empresas, nem todos vivem à pendura da pseudo-investigação suportada pelo QREN. Pensa nisto.



Mas pensando bem, esta Sony é a mesma Sony que caça judicialmente utilizadores que tratam as consolas com compram como deles, nem sei porquê é que isso me admira.

Certo. E tú ligas-te à internet através de um operador de telecomunicações que fornece ao SIS e amigos informações que nao deveriam ser fornecidas sem mandato judicial. Todas as tuas chamadas telefónicas são gravadas e mantidas durante um periodo de 7 anos. O teu ISP passa informação estatistica a organizações como a MAPINET para perseguirem os mesmos utilizadores... etc.. etc etc...

De qualquer forma, existe uma falha no teu pensamento, a Sony nao persegue utilizadores, persegue sim alguns que criam e desenvolvem chips para contornar os sistemas de segurança das consolas, como se passou com o caso dos criadores do Matrix para a PS2.

Um utilizador pode comprar uma consola, no entanto nao pode simplesmente fazer o que quer porque existe tecnologia protegida dentro da mesma.

Tens uma XBox ? :)



Já que somos tão livres porquê é que insistem em não nos deixar arrancar outro SO na playstation?

Isso deverias investigar por ti. O objectivo da Sony é vender consolas a consumidores finais, nao é venderem consolas para empresas e organizaçoes construirem super clusters de 40.000 PS3 para calculo vectorial ou para utilizarem componentes para sistemas de misseis caseiros. Acho que foi mais por aí e nao propriamente devido ao pessoal do Linux ou hobby's. Se nao estou em erro foi precisamente o DoD que fez o cluster de 40.000 PS3 (posso estar enganado).



O KMS está dependente de código ser linkado ao kernel, não atuar como um módulo, ser parte do kernel.

Nao linkas codigo contra o kernel, possivelmente linkas simbolos ou seja la qual for a traduçao para brazuca.



Qual seria a solução ideal? Permitir que as NVidias, ARMs, Imaginations, Qualcoms e quem mais queira atire os blobs que bem entendam para dentro do kernel?

O ARM nao deveria estar nessa lista. Imagina que queres fazer um telefone baseado em ARM. Falas com os tipos, pagas e eles enviam-te as especificaçoes pelo correio. Depois contratas uma empresa para a produção. O que algumas empresas fazem, como a Samsung no passado é javardarem nas especificaçoes e alterarem coisas que fazem com que alguns ARM nao sejam exactamente iguais às especificaçoes originais e sim 'filhos bastardos'. ARMs puros sao muito bem suportados, os filhos bastardos, nem sempre.



Quem garante o que está dentro dos blobs? E se lá estiver um backdoor?

Nao usas Cisco para core switching? Quem te garante que nao tem uma backdoor? Nao usas firewalls fortinet, checkpoint, etc?
Deixa-me ver, tens um netfilter a fazer coreswitching? :) (nao gozo porque existe uma empresa em Portugal pelo menos que o faz e muito bem).



Dizes que licenças permissivas são liberdade, mas então e a liberdade do utilizador saber o que foi anexado ao núcleo do seu SO, aquela parte que consegue fazer o que bem quiser com o computador?

Essa liberdade já a perdeste para os fabricantes de hardware. E digo-te apenas uma vez: consulta as especificaçoes da ACPI, e depois ve a implementaçao da tua board. Vai lá chatear a Asus por estarem a atentar contra a tua liberdade, apesar de ser uma opçao de compra tua!!


- "Se queres utilizar o que fiz, força, mas retribui com o que fizeres"

Numa situaçao diferente, eu chamaria-lhe hipocrisia e chantagem ?! Mas nas licenças é diferente!


- "Não quero saber, faz o que quiseres, guarda, dá de comer ao cão, não me ralo minimamente, apenas deixa o meu nome ai"

E o ficheiro de licenciamento ;)


Mas se quiseres ver o que faz o TEU telemóvel és livre de o fazer, o código anda por ai.

O meu sim, porque comprei um telefone com equipamento standard, no entanto se for um Samsung eu nao posso por exemplo ver o driver da camara entre outras coisas. Os blobs estao la. Alias, o bootstrap de um android preve mesmo a existencia de blobs.... E sim isto é liberdade...



Não pintei a google como santa, pelo contrário interpretaste mal. O android é praticamente um walled garden, e o GPL não proibiu que isso acontecesse. Continua-se a poder ver o código e fazer forks, mas a partir do momento em que se quebre a compatibilidade com os APKs, ou nem tanto, se perca o acesso à PlayStore perde a maior parte da relevância. Eles conseguiram isolar o ecossistema deles mesmo estando a utilizar a licença que mais força a partilha

Desculpa lá se o que escrevo aparenta estar em tom de rant, apenas estou a tentar não me extender demasiado e ir direito ao tema sem fugir demasiado ao tópico :p


Sem stress.... Só uma coisa em relaçao ao android: ANDROID = DATA MINING.
 
As contribuições em dinheiro continuam a serem superiores às da ANSOL ou outras empresas Portuguesas que se tentam afirmar como open source. Por outro lado a Sony é um dos players mais fortes dentro do mundo do open hardware?!
Comparar uma empresa globalizada que emprega +100k, muitos desses na area técnológica com uma non-profit local cuja causa principal é a promoção não parece lá muito justo.
Curiosamente, a utilização da GPL está a cair em deterimento de outras licenças mais livres. Entre 2009 e 2016 a GPL perdeu perdeu perto de 20 pontos percentuais face a outras licenças mais permissivas. Inclusivé, a ineficiencia da GPL é clara devido à necessidade de muitos projectos terem que por licenciamento duplo, GPL + LGPL. Como te disse é uma preferencia pessoal da minha parte.
Ad Populum. E as licensas que defendes eu também as considero boas, não penses que não.
A meu ver a vantagem logo a primeira vista é serem diretas ao tema. 4 termos e está tudo feito.
Eu não considero a GPL perfeita, apenas prefiro, isto é tudo subjetivo.
Até a WTFPL é okay-ish, mas quanto menos uma licensa assegure os direitos, mais simples é de abusar.
DO WHAT THE ***** YOU WANT TO PUBLIC LICENSE
Version 2, December 2004

Copyright (C) 2004 Sam Hocevar <[email protected]>

Everyone is permitted to copy and distribute verbatim or modified
copies of this license document, and changing it is allowed as long
as the name is changed.

DO WHAT THE ***** YOU WANT TO PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

0. You just DO WHAT THE ***** YOU WANT TO.
É ao contrário. Quem desenvolve os drivers é a AMD, pelo que na realidade ao utilizar um micro kernel BSD, o licenciamento do mesmo nao interfere e permite que a AMD continue a manter o seu driver para o hardware em questão. Nao é a sony que desenvolve os drivers.

A AMD é um fornecedor, nao tem que ter incentivos, tem que responder ao que lhe é solicitado. Ou entrega valor ou nao entra no negocio, e para entregar valor tem que ter as coisas a funcionar de acordo com o que é esperado porque no final o sucesso de uma plataforma PS4 ou equivalente é ditado pela performance e pela satisfaçao dos consumidores.
Ponto concedido.
A AMD assim como a Intel e outras empresas estão dedicadas porque é a nova trend da industria, e como dependem da venda de hardware para sobreviverem, ou respondem ou nao morrem. Isto é uma questao de exigencia de mercados e nao ideologica.
As tendências ditam-se pela quota de mercado, e neste momento a NVidia têm mais quota de mercado do que a Intel e a AMD perante quem dá uso ao GPU para mais do que um browser.
Acredito que a AMD e a Nvidia estejam a demonstrar abertura por acreditárem que os clientes valorizam isso, mas não é essa a tendéncia. Então no caso da NVidia cada vez menos abertura há, ainda até recentemente Maxwell ficaram 1 ano a aguardar firmware.
Certo. E tú ligas-te à internet através de um operador de telecomunicações que fornece ao SIS e amigos informações que nao deveriam ser fornecidas sem mandato judicial. Todas as tuas chamadas telefónicas são gravadas e mantidas durante um periodo de 7 anos. O teu ISP passa informação estatistica a organizações como a MAPINET para perseguirem os mesmos utilizadores... etc.. etc etc...
Isso foi legislado, o povo é que vota, logo foi liberdade nossa de escolher que assim fosse mesmo que não agrade a muitos. Pode ser que nos venhamos a educar mais, até lá não é senão culpa nossa.
De qualquer forma, existe uma falha no teu pensamento, a Sony nao persegue utilizadores, persegue sim alguns que criam e desenvolvem chips para contornar os sistemas de segurança das consolas, como se passou com o caso dos criadores do Matrix para a PS2.
Oopsie, empresa errada. Pensei que tivesse sido a Sony quem tinha andado a abater o pessoal do homebrew. Então já não sei quem foi, tinha de procurar. Já vi que eles até tiveram o 'Other OS'.
Um utilizador pode comprar uma consola, no entanto nao pode simplesmente fazer o que quer porque existe tecnologia protegida dentro da mesma.
Tal como dentro dos nossos computadores. Também tem codecs em HW e DRM em SW, e não é por isso que não podemos cuscar o que se passa por lá. Depende do que se faça. Claro que se quebrar o mecanismo do primetime e andar por ai a gabar-me e expor, sou capaz de arranjar um ou outro problema, mas posso tentar. :biglaugh:
Tens uma XBox ? :)
Ultíma consola PS2, PCMR since then
O objectivo da Sony é vender consolas a consumidores finais, nao é venderem consolas para empresas e organizaçoes construirem super clusters de 40.000 PS3 para calculo vectorial ou para utilizarem componentes para sistemas de misseis caseiros. Acho que foi mais por aí e nao propriamente devido ao pessoal do Linux ou hobby's. Se nao estou em erro foi precisamente o DoD que fez o cluster de 40.000 PS3 (posso estar enganado).
O objetivo da Raspberry PI é vender computadores low-cost a quem não tem outra forma de se introduzir á computação e eletrónica, e não fazer media-centers.
Sim, eu lembro-me disso, mas se der para mais coisas, porque não? É dinheiro a entrar de qualquer forma.
Ah, pois, porque vendem Playstations/XBox'es/etc... abaixo do preço de fabrico e esperam rentabilizar com jogos.
Posso estar em erro, mas isso é ilegal em boa parte do mundo caso se consiga provar.
O ARM nao deveria estar nessa lista.
As Mali são desenhadas por eles, cabe-lhes a eles fazer a driver.
Nao usas Cisco para core switching? Quem te garante que nao tem uma backdoor?
Um fazer mal não é desculpa para os restantes poderem fazer. Ciscos e essas empresas deveriam no minimo dos minimos de permitir audits a fundo por parte dos clientes. E mesmo assim... http://arstechnica.com/tech-policy/...de-factory-show-cisco-router-getting-implant/
Continuo na minha, um hardware com um blob é mais uma vulnerabilidade no computador.
Essa liberdade já a perdeste para os fabricantes de hardware. E digo-te apenas uma vez: consulta as especificaçoes da ACPI, e depois ve a implementaçao da tua board. Vai lá chatear a Asus por estarem a atentar contra a tua liberdade, apesar de ser uma opçao de compra tua!!
Eu já tenho trabalho a chatea-los para que me re-embolsem o Windows, quanto mais ir melgar os gajos com implementações de ACPI. Haviam de me mandar a um sitio agradavel...
Esta é uma das coisas que está dependente da vontade das massas. Se as massas não permitirem eles não fazem. Educação é tudo.
Numa situaçao diferente, eu chamaria-lhe hipocrisia e chantagem ?! Mas nas licenças é diferente!
Um pedido de retribuição ao trabalho do criador? Não apanhei a ideia.
De que forma é que isso é mau? Eu fiz x, se quiseres fazer y, um produto derivado de x, tem que ter as mesmas condições.
Parece-me um pedido razoavel, só come quem quer.
Alias, o bootstrap de um android preve mesmo a existencia de blobs.... E sim isto é liberdade...
São modulos, não uma parte integrante do SO. Claro que considero isso mau, mas não viola a licensa.
A única forma de prevenir isso seria com uma licensa ainda mais restritiva.
Assim tens meia duzia de blobs, com liberdade total terias perto de 100% de blobs. Pick your poison.
ANDROID = DATA MINING.
Nunca disse duvidar disso. Falta-ta a camisola e o cartaz para dar enfase. :002:
 
- AMDGPU DRM Driver Updates To Work With Production Polaris GPUs
With Polaris the initial kernel-side code is coming in Linux 4.7 as the first kernel with the big changes needed to the kernel driver. In user-space you'll need Mesa 12.0+.

While the code has already been mainlined in Linux 4.7, it looks like some changes are needed to this code for supporting the production Polaris GPUs. Alex Deucher of AMD today mailed out "Polaris updates for production silicon" that contain 444 lines of new code and 139 lines of deleted code.
http://phoronix.com/scan.php?page=news_item&px=AMDGPU-Polaris-Updates


- AMDGPU Fixes For Polaris Queuing Up For Linux 4.7
Alex Deucher of AMD sent in the -fixes pull request today for the AMDGPU DRM driver. He commented, "A bit bigger than I would normally like, but most of the large changes are for polaris support and since polaris went upstream in 4.7, I'd like to get the fixes in so it's in good shape when the [hardware] becomes available. The major changes only touch the polaris code so there is little chance for regressions on other [GPUs]. The rest are just the usual collection of bug fixes."
http://phoronix.com/scan.php?page=news_item&px=AMDGPU-Polaris10-Fixes-4.7

e ainda

Radeon RX 480 Linux Testing Is Happening Right Now

sd2vlk.jpg


O Michael recebeu uma RX 480 para testar :banana:
 
Some Of The AMDGPU Changes Being Worked On For Linux 4.8

One of the changes we're looking forward to most with the AMDGPU DRM of Linux 4.8 is the OverDrive overclocking support.
...
Another change being looked for with Linux 4.8 AMDGPU is the experimental GCN 1.0 support for allowing the original GCN GPUs of the Radeon HD 7000 series (and re-brands in the Rx 200/300 series) to work with this newer DRM driver and thus too the AMDGPU-PRO driver with Vulkan support.
...
Various bits of hybrid platform code and other changes around hybrid GPU laptops...
http://phoronix.com/scan.php?page=news_item&px=AMDGPU-Linux-4.8-Early-Look
 
Adicionados patches que permitem adicionar suporte inicial aos gpu GCN 1.0 ao AMDGPU

GCN 1.0 / Southern Islands On AMDGPU Takes Another Step Forward

One of the remaining items being tackled now for Southern Islands is DPM (Dynamic Power Management) support and it looks like that too may be squared away. AMD developer Huang Rui published a set of 14 SI DPM patches. He says that with these patches the Southern Islands hardware should now have "workable" support.
http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-SI-DPM
 
Bom continuando o meu monólogo, com o lançamento da VEGA

Radeon RX Vega On Linux: High-Performance GPUs & Open-Source No Longer An Oxymoron

The Radeon RX Vega Performance At Day One
-
-with the OpenGL results near universally the RadeonSI OpenGL performance was noticeably faster than the AMDGPU-PRO hybrid driver with its proprietary OpenGL driver.

Where The Radeon Linux Driver Stack Has Room To Improve
- There remains no "Radeon Software Settings" (or formerly Catalyst Control Center Linux Edition) currently for either AMDGPU-PRO or AMDGPU+RadeonSI.
- There still are some features not supported by the Linux driver stack.
http://www.phoronix.com/scan.php?page=article&item=rx-vega-linux1&num=1

o que em parte é explicado pelo Bridgman na secção de comentários:
Vega10 was the first time we tried running Linux drivers on the emulator - there is a fair learning curve and we didn't get very far by the time silicon came back, but for the next generation of chips we are starting on the emulator in parallel with the Windows devs.
https://www.phoronix.com/forums/for...rce-no-longer-an-oxymoron?p=969732#post969732
 
Parece já faltar pouco, finalmente foi submetido o pull request para o DC, a ver quando entra no drm-next

AMDGPU DC Pull Request Submitted For Linux 4.15: Finally The New Display Stack

It has yet to be pulled into DRM-Next, but last night Alex Deucher did what many AMDGPU users have been waiting years to see: submitting the DC display stack PR to DRM subsystem maintainer David Airlie.

This DC display stack is what provides physical display support for RX Vega graphics cards, HDMI/DP audio, DP MST, atomic mode-setting for GCN 1.1 and later, the basis for FreeSync, and many other modern display features. AMDGPU DC was formerly known as "DAL" and has been in development for years and already is used by the AMDGPU-PRO driver. The DC display code more unifies the display code between Windows and Linux for AMD GPUs.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-PULL-REQUEST
 
Vamos aguardar primeiro para ver se vai ser aceite para o DRM-next, assim que for é o habitual processo de revisão. Mas para o 18.04 é previsível que sim.
Para quem usa rolling distros não fará grande diferença, uma vez upstream e merged é esperar até estar nos repositórios, espero que venha antes de Abril ;)
 
Mais umas quantas alterações:

Harry Wentland of AMD today sent out 103 more DC patches of this new display code implementation for the AMDGPU Direct Rendering Manager driver.

Prominent changes include a hang fix for hotplug displays, hotplug not working after S3 suspends, multi-display support for Carrizo, more Raven Ridge APU enablement, updated DML code (described by Harry as a "GCC parseable hardware gospel"), a frame-buffer compression configuration option, corrected audio assignment, and other fixes.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-103
 
RadeonSI/RADV Mesa 17.3 + AMDGPU DC vs. NVIDIA 387.12 Linux Gaming Performance

The open-source AMD Radeon tests were done using the AMDGPU DC branch of the new code that's being queued for the Linux 4.15 kernel and will finally allow mainline display support for Radeon RX Vega graphics cards. The user-space components included Mesa 17.3-dev as of this week built against LLVM 6.0 SVN for the AMDGPU compiler back-end, as packaged via the Padoka PPA for Ubuntu 17.04. The tested Radeon graphics cards for this comparison were the Radeon RX 580, R9 Fury, RX Vega 56, and RX Vega 64.
VS
On the NVIDIA side was the 387.12 beta driver as their latest public Linux graphics driver. The tested GeForce cards were the GTX 980, GTX 1060, GTX 1070, GTX 1080, and GTX 1080 Ti.
https://www.phoronix.com/scan.php?page=article&item=mesa173-dc-nv&num=1

With some exceptions, overall Mesa 17.3 with RadeonSI and RADV is running fairly well against the NVIDIA Linux driver and the current selection of GeForce graphics cards. On the RadeonSI OpenGL front is where Mesa 17.3 is fairly competitive with NVIDIA for Linux gaming, but on the RADV Vulkan driver side there is still headway to be made.

Como nota: o RADV Vulkan não é o driver da AMD, que ainda não está pronto (leia-se não é Open Source), pelo que este RADV Vulkan é baseado no ANV Vulkan da Intel, acho que foi feito por um developer da Red Hat.
 
Game on!
Linus Torvalds has accepted the AMDGPU DC display code pull request for the Linux 4.15kernel. AMD Linux users can now rejoice!
With Linux 4.15, AMDGPU DC is just enabled by default for Vega hardware. If you are on GCN 1.1 or newer with AMDGPU and want to use DC, you need to use the amdgpu.dc=1 kernel module parameter for activation.
https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-Accepted

De referir que se pode dar o caso de o FreeSync pode não ser incluído no DC, isto porque o Nicolai Hanle tinha deixado a ideia de dado que isto é standard da Displayport, devia ser incluído no Mesa e não nos drivers, alguns OSS developers da Intel mostraram interesse, a ver.

Já agora foi igualmente lançado o VCN, o novo média encoder/decoder que substituirá o VCE e UVD.
"Video Core Next" supports MPEG-4 AVC and HEVC/H.265 encoding while on the decoding front is MPEG-2, MPEG-4, VC1, MPEG-4 AVC, H.265 HEVC, and VP9. Most likely VCN will premiere on the desktop side with next year's Navi architecture.
https://www.phoronix.com/scan.php?page=news_item&px=Radeon-VCN-Encode-Lands
 
Está quase tudo, uma das últimas coisas que faltavam
AMD Open-Source Driver For Vulkan "AMDVLK" Is Now Available
AMDVLK
This driver that's now open-source is the official AMD Vulkan driver -- what up to now was available via the AMDGPU-PRO driver and shared with the Radeon Windows Vulkan driver. This open-source Radeon Vulkan driver is not to be confused with "RADV" that is the community-driven Radeon Vulkan driver living within Mesa and continues to be developed independently of AMD.

AMD will be publishing precise build instructions for Red Hat and Ubuntu systems for those wanting to try out the AMDVLK driver on their own. For now AMD just lists Ubuntu 16.04.3 LTS and Red Hat Enterprise Linux 7.4 as the supported operating systems.
https://www.phoronix.com/scan.php?page=article&item=amdvlk-radeon-vulkan&num=1

Neste momento ainda apenas nos repositórios, e apenas para kernels LTS, mas rapidamente deve estar disponível para download.
 
Back
Topo