Olá, hoje vou contar um pouco da minha experiência como usuário de desktop (principalmente do Fedora) com placas de vídeo Nvidia x AMD.

Comecei usando placas Nvidia, já tive gtx 460,560,780 e 1060 3GB. Tenho maior experiência com Nvidia do que AMD, mas atualmente estou usando a RX6600 (desktop) e R7-5700u RX Vega 8 (notebook). Também ja tive a RX 580.

Instalação

Primeiro ponto, relativo a instalação e uso prático de drivers das placas.

Nvidia

https://www.youtube.com/watch?v=i2lhwb_OckQ
Para começar com o famoso dedo do Linus para Nvidia a muitos anos atrás, a situação, em muitos aspectos ainda continua, mas trata-se principalmente dos problemas com “Nvidia hibridas” de laptop’s, experiência que nunca tive (graças a Deus) pois a experiência é pior que placas dedicadas em desktop.

Com Nvidia nunca tive grandes problemas para instalação de driver, isso por que não fui atrás de qualquer tutorial por aí, aliás, já testei e comprovei na prática que muitos tutoriais sobre instalação de driver nvidia são furados. E seguir o procedimento recomendado da sua distribuição (toda distro tem em sua documentação um tópico dedicado a Nvidia) ou repositório (no caso RPMFusion para Fedora, Debian nonfree para Debian etc) assim é a forma mais garantida de sucesso. Talvez não usar uma distribuição Linux muito “exótica” ou as famosas “refisifuques” pode ajudar na experiência, pelo fato de ter menos mão de obra / testes do que um projeto com grande comunidade e testadores…

“siga a recomendação da sua distribuição, se for seguir tutorial, teste e confira se está de acordo com a documentação oficial.”

Todavia, se você é um fuçador/testador que modifica o sistema a ponto de trocar kernel’s seguidamente, a chance de quebrar é grande. O principal driver da Nvidia é proprietário, é o driver mais usado e que recebe mais atenção dos mantenedores que corrigem bug’s em todas versões.

Existe driver open source “nouveau” mas é constituído de muito trabalho de engenharia reversa e das especificações básicas dadas pela Nvidia, ou seja, o Nouveau não é ruim por culpa dos dev’s, mas sim da empresa fabricante da placa, que praticamente não se envolve com o desenvolvimento do Nouveau.

Existe driver Vulkan open source para Nvidia (NVK) que está ganhando muito desempenho e compatibilidade, mas atualmente ainda falta muito para alcançar o proprietário.

O driver ser proprietário, quer dizer que não está “embutido” no kernel Linux, por isso a troca de kernel (feita inconsequentemente) pode causar problemas com driver Nvidia, assim como a instalação do driver pode ser complicada dependendo da distros / usuário / placa etc…

Dito isso, devido a falta de integração / interesse da Nvidia com o Linux e sua natureza closed source, coisas assim podem acontecer, não muitor frequentemente, mas você nunca sabe o que pode vir em um novo update de kernel / driver.

Uma configuração na BIOS é necessária em todas as distros ao usar driver Nvidia, é o secureboot que é necessário desativar (existe maneira de como contornar isso mas exige algum conhecimento e leitura de documentações).

Então quer dizer que se usar uma distribuição que atualiza seguidamente o kernel, terei problemas?

Não necessariamente, no caso do Fedora usam recursos via akmod’s. Que basicamente “reinstalam” os modulos/drivers Nvidia a cada nova versão de Kernel instalado/atualizado. O processo é automaticamente feito no boot e geralmente não leva mais de 1 minuto. Além de o driver passar por uma curadoria / QA antes de ser lançado em updates aos usuários.

Em distribuições como o Arch Linux, o driver está nos repositórios que é atualizado, ou não (de acordo com o QA da distro) sempre que disponível. Se a atualização do driver não quebrar, eles enviam o update para os usuários, do contrário seguram.

No openSUSE existe repositórios (diretamente dos domínios da Nvidia) dedicado para Driver Nvidia, compatíveis para versão enterprise (Leap) e a versão mais atualizada (Tumbleweed) na qual também passam por QA.

E assim por diante, cada distribuição se encarrega de manter os binários Nvidia, compatíveis com os updates das suas respectivas versões. Mas em todas, desativar o secure boot será necessário. Inclusive a distribuição PopOS que dedica uma .iso para Nvidia, avisa sobre o secureboot antes do download:

Resumindo, não é uma boa você (usuário comum de desktop) baixar o binário do site e instalar por conta própria. Apesar de ser possível, caso saiba o que está fazendo.

Distribuições como Ubuntu / PopOS tendem a ser mais amigáveis a drivers Nvidia (PopOS não para Nvidia legacy) principalmente com as problemáticas placas híbridas de notebook, pois já trazem o driver pré instalado no sistema, mas claro, que isso não isenta de ter problemas, aliás é o que mais vejo em fóruns pela internet, pois acaba sendo a porta de entrada de muitos usuários de Nvidia.

Placas híbridas, são um capítulo a parte, algo que não recomendo para ninguém. Se com placas de desktop pode ser preciso alguma ação externa da distro/usuário para fazer funcionar, com as híbridas pode não haver o que fazer por pura falta de suporte da Nvidia.

AMD

Instalação manual de driver (amdgpu ou radv) não é necessário, pois está no kernel Linux, todavia se você usa Debian free, terá que instalar firmwares do repo nonfree para funcionar (nas ultimas versões do Debian incluem firmwares desde o instalador). Tirando esta acessão de distro, é instalar o OS, a Steam e jogar!

Existe driver proprietário da AMD, porém é destinado ao uso em sistemas enterprise e com foco nas tecnologias gráficas de renderização/composição/encoder (O Davinci Resolve/Blender (teoricamente) são compatíveis).

O driver proprietário da AMD para Linux pode gerar inúmeros problemas de integração com app’s de desktop comuns, como: players de video, navegadores e DE’s/compositores, além de problemas com jogos nativos ou via Próton/SteamPlay. Então se realmente precisa do driver proprietário para uso do OpenCL em algum programa (como Davinci Resolve ou Blender) recomendo usar com um sistema dedicado a isso.

Existe implementação OpenCL aberta via rocm, testei aqui. Funciona bem, porém tem pouco suporte em geral, apesar de ROcm funcinar com Blender(rocm-hip) e Davinci Resolve(rocm-opencl).

O amdgpu (driver open source default no Kernel Linux) tem mais atenção de mantenedores da Valve, Intel, RedHat, Mesa e inclusive da própria AMD, ou seja, quando encontram bug’s em jogos, a chance do report e correção vir primeiro para o mesa/amdgpu/radv e toda stack gráfica, são grandes. Claro, nada disso adianta se usar uma distribuição que congela as versões, Flatpak resolve isso!

Um fator importante para placas AMD é ter pacotes mesa/kernel relativamente atualizados. Não é preciso usar uma distribuição bleeding edge ou rolling release tipo ArchLinux, mas usar um Debian old stable sem backports é pedir para encontrar incompatibilidades. Na parte de Mesa basta usar Flatpak (Steam Flatpak) e kernel não creio que hoje em dia verá diferença de desempenho clara, mas talvez falta de compatibilidade caso tenha hardware muito recente.

Existe um problema causado por uma desinformação, onde o usuário comum que acabou de comprar sua placa de video do ano (problema não tão comum aqui no BR) escolhe um sistema “user friedly” porém, este mesmo sistema congela versão de pacotes/drivers e pode levar meses para fazer backport (isso quando faz) dos novos drivers ou atualização de compatibilidade com novos hardwares (falo de distros geralmente LTS) levando a problemas de incompatibilidade.

Mas resumindo a situação dos drives AMD:

Driver open source = melhor experiência pronto para uso.

Driver closed = pior experiência e não vem pronto para uso.

Tweak’s e centro de controle/monitoramento

Nvidia

Junto com o driver Nvidia, geralmente vem o pacote “nvidia-settings” (este da imagem acima, que parece ter saído do Windows XP!) que é uma interface gráfica para gerenciamentos específicos da placa/driver que não estão integrados a DE ou o próprio sistema.

E sim, usuários Nvidia no Linux tem um settings de “2° classe” comparado ao settings no MS Windows.

Os principais tweaks neste settings são relativos a ajustes necessários usando X11/Xorg (outra tecnologia antiga e problemática) por exemplo: controles de filtros de cores/imagem/processamento, consumo energético, desempenho, monitoramento de temperaturas, clock, resolução da tela (esta última é integrada na DE) etc.

É uma ferramenta fantástica e também avançada, algumas opções podem exigir privilégios de super usuário/root, como para salvar um perfil de configurações avançadas ou liberar alguns recursos travados por padrão.

O nvidia-settings é necessário para ativação de opções como o “composittion pipeline” que elimina (tenta) o tearing que possa haver em jogos, compositores de janelas, app’s gráficos, navegadores… quando usando sessão Xorg/X11, a custo de algum desempenho, que pode ser muito pouco para perceber ou não, depende da placa.

É uma opção que não vem ativa por padrão e usuários de primeira viagem que estiverem usando a sessão X11/Xorg, podem não saber da sua existência podendo sofrer com a tela rasgada.

Para monitoramento de temperaturas, pode-se usar o próprio nvidia-settings. Para informações “ingame” existe uma opção no próprio do nvidia-settings (porém não mostra frametimes) ou ferramentas open source como: Vulkan Overlay, DXVK_HUD e MangoHUD.

Para monitoramento “externo” a um app / jogo, existe o próprio nvidia-settings, GreenWithEnvy e Nvidia System Monitor (estes são os que conheço).

AMD

Se com Nvidia não possui uma integração “out of the box” com as DE’s/distribuições/kernel Linux, com AMD é ao contrário, você não vai precisar fazer nada para resolver tearing, pelo menos usando driver amdgpu open source + Wayland (tecnologia moderna que substitui o X11/Xorg). Ele vem basicamente no modo “pronto para jogar” e não precisa de tweak’s.

Porém, se você quiser ter maior controle das configurações e monitoramento da GPU AMD, não existe um “centro de controle oficial” como o horroroso nvidia-settings da Nvidia.

Existe algumas soluções open source, algumas tem controle de clock/fan, monitoramento de temperaturas… porém nem todos softwares funcionam em todas placas e podem necessitar de procedimentos muito complexos para usuário comum.

Uma ferramenta muito interessante chamada “coreCtrl” está nos repositórios do Fedora e tem o objetivo de oferecer controle do hardware em geral, criação de perfis etc:

Para monitoramento de temperaturas, pode-se usar também o próprio lm_sensors ou qualquer GUI que faça uso dele. Para informações “ingame” como contador de FPS, frametime… existe ferramentas como GALLIUM_HUD para OpenGL, Vulkan Overlay e MangoHUD.

Compatibilidade de Software / Games

Este é um ponto que não vi diferença na parte de jogos, pois hoje em dia, a compatibilidade está muito diferente do que foi a alguns anos, jogos eram portados sem compatibilidade com Mesa (usado com AMD e Intel). Hoje em dia até os jogos antigos (teoricamente sem suporte) estão rodando com AMD/Mesa.

Todos os jogos de minha lib na Steam rodaram com AMD/Nvidia, tanto os nativos quanto via Proton. Tive mais casos de bug’s corrigidos em atualizações de driver Nvidia, porém por conta do maior tempo de uso. É bem possível que se eu tivesse começado a usar AMD no desktop Linux, teria passado por mais bug’s e incompatibilidades também.

Mas veja, o Proton da Valve tem foco em AMD GPU e não é muito raro encontrar jogos que rodem melhor em AMD GPU por conta disso, exemplo do Forza Horizon 5 que ficou meses com crash com Nvidia, até a mesma lançar alguma correção, enquanto com AMD, desde que o Proton compatibilizou passou a rodar bem, pelo menos, com as AMD de arquitetura RDNA2+ (mesma do Steam Deck).

Existe incompatibilidades de drivers ou recursos dos drivers AMDGPU (driver open source) com programas que precisam de implementação OpenCL proprietária (OpenCL que vem no driver proprietário da AMD) como: Davinci Resolve e Blender. O encoder via hardware AMF da AMD funciona apenas com driver proprietário da AMD, mas não é suportado oficialmente por programas como OBS Studio no Linux.

O driver proprietário / fechado da AMD, é suportado apenas para UbuntuLTS / SUSE / RHEL e em versões específicas destes sistemas e não são muito sincronizados com pequenas atualizações dos sistemas, ou seja, pode ser complicado manter um sistema assim para um usuário comum. Este mesmo driver proprietário da AMD não é recomendado para games em geral.

Na grande maioria dos casos, apenas usar o driver open source padrão irá ser o suficiente.

O Fedora está portando o driver OpenCL via ROCm, para que se possa usar o OpenCL + drivers open source AMD. Veja demonstração aqui.

A Valve que contribui muito com as ferramentas de compatibilidade de jogos de Windows no Linux (Próton, wine, dxvk etc) foca em hardware e stack gráfica open source, seu SteamDeck usa GPU AMD inclusive.

Gravação de tela / encoders

Este é um ponto que comparo NVENC (nvidia) e VAAPI (amd/intel). São os encoders via hardware, necessários para fazer gravação de tela sem usar muito CPU, evitando lag enquanto joga/transmite.

A AMD possui o encoder AMF, porém funciona apenas com driver proprietário (o mesmo driver que não é recomendado para games) e não é oficialmente suportado no OBS Studio para Linux sem plugins ou modificações do próprio OBS por terceiros. Em meus testes está igualado em desempenho com o atual VAAPI (que é compatível com drivers open source).

No geral consegui fazer boas gravações com a GTX 1060 / Nvenc e VAAPI com a RX 580/RX 6600, principalmente com VAAPI, que atualmente está em um nível de desempenho muito bom, principalmente com plugins como: Gstreamer + gamecapture (este não é compatível com Nvidia) como mostro aqui.

Compatibilidade com tecnologias open source

Se você usa desktop Linux (independente da distros/DE) então usa muitas tecnologias open source, creio ser um ponto interessante para você!?

Este é um ponto que mais me agradou na AMD, pois sou o tipo de usuário “entusiasta” e gosto de testar novas tecnologias (como foi com Wayland) sendo assim, usar Wayland com Nouveau ninguém merece, pois o desempenho é ruim por conta da questão de falta de suporte da Nvidia.

O driver proprietário da NVidia apartir da versão 470, teoricamente tem compatibilidade com Wayland e atualmente está usável com alguns “pequenos grandes” detalhes a serem resolvidos pela Nvidia.

Já usava GNOME Wayland a um bom tempo em meu notebook com Intel e queria ter a mesma experiência no desktop (um dos motivos de ter adquirido uma GPU AMD).

Creio que a compatibilidade / otimização com compositores e DE’s também é melhor com AMD, por usar tecnologias nativas e integradas com o sistema, porém as vezes a diferença pode ser algo mais sutil, dependendo do usuário ou situação, talvez nem note a diferença usando gpu nvidia/amd.

Também tive a experiência de um bug de incompatibilidade com Driver Nvidia usando GNOME Boxes (um software que gosto e uso muito). Reportei ao desenvolvedor do Boxes e ele concluiu que simplesmente não podia fazer nada, pois dependia da Nvidia lançar um update para talvez corrigir o problema, isso aconteceu a anos atrás ainda ocorre hoje.

É o tipo de problema que pode ter com drivers proprietários. Drivers open source também podem ter problemas de incompatibilidade, porém são muito raros e corrigidos rapidamente.

Desempenho

Algo que não tenho queixa em nenhuma das marcas, mostrei em muitos vídeos do meu canal, consegui rodar tranquilamente jogos AAA, nem todos no máximo obviamente, mas não tive nenhum problema que me impedia de jogar. Notei um pequeno upgrade em games com vulkan em relação a gtx1060 3GB para a RX580 8GB, mas ao meu ver não foi nada além do esperado. Com a RX 6600 veja aqui.

Open vs Closed Source

Este é um fator que favorece a AMD (partindo do princípio que o open source seja sua preferência) além de seus drivers serem open source e inclusos no kernel, existe mais engajamento de várias empresas e projetos de software.

No lado do desenvolvedor, fica mais fácil integrar suas tecnologias open em outras tecnologias open, pois as coisas são mais transparentes sem depender do suporte nem sempre muito eficaz por parte da Nvidia, a exemplo, por anos é esperado o suporte ao Wayland, problemas / bug’s / inconsistências com compositores de janelas de várias DE’s e softwares em geral, muitas vezes dependem do interesse da Nvidia (isso quando existe) em corrigir os mesmos.

Caindo no problema da compatibilidade de software, ser open não quer dizer ser compatível com tudo, quer dizer que PODE ser compatível com quem tem interesse de implementar.

Este tópico não se trata de uma opção filosófica / religiosa, mas de fatos que as tecnologias abertas possuem vs as fechadas.

Por um lado AMD oferece maior sinergia com tecnologias e stack gráfica nativa do Linux e por questões de mercado e falta de investimentos, não oferece uma “central de configurações oficial” para o Linux desktop ou programas como Davinci Resolve tendem a apoiar mais tecnologias Nvidia (CUDA, optiX), por outro lado, Nvidia oferece compatibilidade com estas grandes ferramentas profissionais e suporte limitado a stack gráfica / DE’s do desktop Linux, além de eventualmente ter problemas em acompanhar os o kernel mainline.

Conclusão: Qual eu recomendo?

Resposta simples, recomendo as duas. Porém sou mais inclinado a recomendar Nvidia para quem pretende usar muito o nvenc e cuda/optiX (streamers, editores e artistas 3d profissionais..).

Creio que o VAAPI esta um pouco atrás do Nvenc na questão otimização no streaming/screencast, mas acho que hoje é totalmente usável para estes propósitos.

Se precisar do OpenCL com AMDGPU recomendo usar rocm-opencl (para Davinci Resolve) e HIP para Blender. Partindo do princípio que iriá usar a stack gráfica open source da AMD.

Já para quem quer o máximo de compatibilidade com tecnologias open source e experiencia mais “out of the box” creio que é mais seguro a recomendação de GPU AMD.

Se não se importa nem com o uso do Nvenc da Nvidia ou os benefícios de usar placa com driver open source e quer “apenas jogar no Linux” ainda tendo a recomendar AMD, porém da arquitetura RDNA2+.

Lembrando que, a Valve escolheu AMDGPU para o SteamDeck, na qual ela mantem o Proton (usado por todos os gamers do Linux) e o mesmo recebe mais atenção para stack gráfica open source (AMD).

E sim, se você acha que minhas opiniões podem estar “contaminadas” devido minha experiência com GNOME, você está certo!

Apesar de eu não ter tido experiências “muito ruins” com GNOME + Nvidia + Xorg, eu aprendi que é uma batalha perdida com driver Nvidia, sempre em algum update o driver poderá falhar, ter incompatibilidade com um novo kernel ou novas tecnologias. Isso porque o Linux não é prioridade para a empresa (que é a única que pode e mantém o driver).

Com AMD, a única distribuição que não tive uma boa experiência default foi no Debian, mas é uma questão de saber usar os repositórios da distro e atualmente a situação parece ter melhorado.

Embora usando drivers open source da AMD não te garanta imunidade de bug’s ou regressões, na minha experiência são corrigidas mais rápido que eu possa notar, creio que por existir muito mais pessoas e empresas envolvidas em toda stack gráfica do Linux, do que a equipe de driver da Nvidia para o Linux.

Se deseja me dar sugestões, mande para fastos2016@gmail.com ou nas redes sociais.