Driver hackeado da GPU Nvidia 4090 ativa P2P
(github.com/tinygrad)- Este repositório é a release de código-fonte dos módulos abertos do kernel da GPU NVIDIA para Linux, e a versão indicada no README é 565.57.01
- Os módulos de kernel compilados devem ser usados junto com o firmware GSP e os componentes do driver NVIDIA GPU em espaço de usuário da mesma release do driver 565.57.01
- O suporte abrange x86_64 e aarch64, e os kernels Linux suportados são os mesmos da versão proprietária do módulo de kernel da NVIDIA, atualmente 4.15 ou superior
- Os módulos de kernel são divididos em componentes independentes do sistema operacional e na camada de interface do kernel Linux, e a camada de interface do kernel deve ser compilada de acordo com o kernel de destino
- As GPUs compatíveis são GPUs Turing ou posteriores, e a tabela lista vários produtos das linhas GeForce, RTX e séries A/H/L, incluindo a NVIDIA GeForce RTX 4090, junto com seus PCI IDs
Release e requisitos de build
- Este repositório é a release de código-fonte dos NVIDIA Linux open GPU kernel modules, e a versão é 565.57.01
- O comando básico de build é o seguinte
make modules -j$(nproc)
- Antes da instalação, é necessário remover os módulos de kernel NVIDIA existentes e executar o seguinte como root
make modules_install -j$(nproc)
- Os módulos de kernel compilados aqui exigem o firmware GSP e os componentes do driver NVIDIA GPU em espaço de usuário da release correspondente do driver 565.57.01
- É apresentado como exemplo instalar o arquivo
.rundo driver NVIDIA GPU com a opção--no-kernel-modules
- É apresentado como exemplo instalar o arquivo
Arquiteturas suportadas e toolchain
- Atualmente, os módulos de kernel podem ser compilados para x86_64 ou aarch64
- Em compilação cruzada, especifique
TARGET_ARCH=aarch64|x86_64junto comCC,LD,AR,CXX,OBJCOPYna linha de comando do make - É possível compilar com versões relativamente recentes do GCC ou do Clang
- A camada de interface do kernel dos módulos deve ser compilada com a mesma toolchain usada para compilar o kernel de destino
- As versões de kernel Linux suportadas são as mesmas suportadas pelo módulo de kernel proprietário da NVIDIA, atualmente Linux kernel 4.15 ou superior
Opções de build
NV_VERBOSE=1exibe todos os comandos executados- Na configuração padrão, apenas linhas resumidas de
CCsão exibidas
- Na configuração padrão, apenas linhas resumidas de
DEBUG=1compila os módulos de kernel em build de depuração- O build padrão é compilado sem informações de depuração
- Esta opção também ativa várias mensagens de log de depuração dos módulos de kernel
Estrutura dos módulos de kernel
- A maior parte dos módulos de kernel da NVIDIA é dividida em dois componentes
- Componente OS-agnostic: parte independente do sistema operacional
- kernel interface layer: parte específica da versão e da configuração do kernel Linux
- No pacote de instalação
.runda NVIDIA, o componente OS-agnostic é fornecido em formato binário- Como esse componente é grande e leva muito tempo para compilar, uma versão pré-compilada é fornecida para evitar que o usuário precise recompilá-lo a cada instalação do driver
- O nome desse componente em
nvidia.koénv-kernel.o_binary - O nome desse componente em
nvidia-modeset.koénv-modeset-kernel.o_binary nvidia-drm.koenvidia-uvm.konão têm componente OS-agnostic
- A camada de interface do kernel de cada módulo deve ser compilada de acordo com o kernel de destino
Estrutura de diretórios e integração com Nouveau
- As funções dos principais diretórios são as seguintes
kernel-open/: camada de interface do kernelkernel-open/nvidia/: camada de interface do kernel paranvidia.kokernel-open/nvidia-drm/: camada de interface do kernel paranvidia-drm.kokernel-open/nvidia-modeset/: camada de interface do kernel paranvidia-modeset.kokernel-open/nvidia-uvm/: camada de interface do kernel paranvidia-uvm.kosrc/: código OS-agnosticsrc/nvidia/: código OS-agnostic paranvidia.kosrc/nvidia-modeset/: código OS-agnostic paranvidia-modeset.kosrc/common/: código utilitário usado pornvidia.ko,nvidia-modeset.koou ambosnouveau/: ferramentas de integração com o driver de dispositivo Nouveau
- Os scripts Python no diretório
nouveauextraem algumas imagens binárias de firmware codificadas no código-fonte e dados relacionados, salvando-os em arquivos separados - Esses arquivos são usados pelo driver de dispositivo Nouveau para carregar e se comunicar com o firmware GSP
- O layout dos arquivos binários é descrito em
nouveau_firmware_layout.ods, que está no formato OpenDocument Spreadsheet
Contribuições e tratamento de issues
- As contribuições são feitas por meio da criação de pull requests no repositório
open-gpu-kernel-modulesda NVIDIA - Ao enviar um pull request, é necessário aceitar o Contributor License Agreement
- Esta base de código é compartilhada com o driver proprietário da NVIDIA, e o código-fonte público é gerado a partir do código compartilhado após vários processamentos
- O repositório no GitHub funciona principalmente como um snapshot de cada release do driver
- É difícil esperar o fornecimento do histórico de revisões de mudanças individuais feitas na base de código compartilhada da NVIDIA
- É bastante provável que exista apenas um git commit por release do driver
- Contribuições individuais podem não ser refletidas como commits git separados no repositório do GitHub
- Devido ao processo de preparação antes da publicação, é necessário merge manual para aplicar contribuições à base de código compartilhada
- Grandes refatorações podem ser difíceis de mesclar e aceitar, exigindo contato e alinhamento prévios
- Problemas relacionados ao Open GPU Kernel Modules podem ser reportados nas Issues do repositório da NVIDIA, nos fóruns de desenvolvedores da NVIDIA ou para
linux-bugs@nvidia.com - Em caso de descoberta de vulnerabilidades de segurança, deve-se consultar o documento separado
SECURITY.md
Faixa de GPUs compatíveis
- Os módulos abertos de kernel da NVIDIA podem ser usados com GPUs Turing ou posteriores
- Para detalhes sobre suporte de funcionalidades e limitações, o texto orienta consultar o documento
kernel_open.htmlno README para usuário final do driver NVIDIA GPU - O suporte a vGPU deve ser consultado no
README.vgpuincluído no vGPU Host Package - A tabela de GPUs compatíveis lista o nome do produto junto com o PCI ID
- Quando há três IDs, o primeiro é o PCI Device ID, o segundo é o PCI Subsystem Vendor ID e o terceiro é o PCI Subsystem Device ID
- A tabela inclui vários produtos, como NVIDIA GeForce RTX 4090, NVIDIA GeForce RTX 4090 D, NVIDIA GeForce RTX 4080 SUPER, NVIDIA GeForce RTX 4070 Ti SUPER, NVIDIA H100, NVIDIA H200, NVIDIA GH200 e NVIDIA L40S
1 comentários
Opiniões no Hacker News
Impressionante. Eu me perguntava se isso era possível; agora, a única coisa impedindo um equipamento 4x4090 para LLMs locais é o tempo de montar
Se a paralelização de tensores funcionar, em inferência parece que será muito mais barato e rápido que uma H100 SXM. Só ainda não entendo por que a tinybox optou por uma configuração com 6 GPUs. Muitas cargas só rodam bem com 4 ou 8; do jeito que está, parece que você paga por 6 e usa só 4, ou fica numa configuração meio-termo por não serem 8
A razão para escolherem 6 é que há 128 pistas PCIe, ou seja, 8 portas x16. Usando 1 para NVMe e 1 para rede, dá para conectar 6 GPUs com fabric completo. Com apenas 4, você desperdiça PCIe; com 8, quase não sobra espaço para conexões externas além de algumas USB3
O objetivo também era rodar modelos 70B em FP16, o que exige cerca de 140 GB de VRAM. 6*24 GB = 144 GB, então fecha certinho
Por exemplo, 4 NVMes exigem pistas x16, e uma rede 10G exige mais x4
O NVIDIA SXM depois foi atualizado para as versões 3 e 4, e essa configuração nem é baseada nele, mas talvez exista algum outro motivo para 6 vias fazer sentido
É uma notícia realmente ótima. Como estou no meio acadêmico, conheço vários laboratórios que montaram máquinas com várias 4090 e não sabiam que a Nvidia havia bloqueado a comunicação P2P entre as placas
Esse também foi um dos motivos pelos quais não comprei 4090, embora fosse muito mais barato para o meu trabalho. Isso não é NVLink, mas, como a Nvidia praticamente eliminou o NVLink de tudo que não sejam suas placas topo de linha, é melhor do que nada. No fim do ano passado recebi uma cotação de 4 H100 com NVLink, e o prazo de entrega era de 13 meses; os produtos sem NVLink podiam ser entregues em 4 meses. Agora comprei 4 L40S para manter o laboratório funcionando, mas os problemas de cadeia de suprimentos e os enormes aumentos de preço estão tornando a pesquisa muito difícil. É muito pouco para dar suporte a 6 doutorandos e vários alunos de graduação
Entre 2015 e 2018, na minha antiga universidade, conseguíamos montar máquinas com 2 GPUs e NVLink por US$ 5 mil cada e colocar uma embaixo da mesa de cada aluno; naquela época era muito mais fácil
Do ponto de vista de um laboratório, acho que eu escolheria a qualquer momento uma placa que custasse 1/4 do preço, mesmo que tivesse metade do MTBF
O que P2P quer dizer aqui? Pesquisando, parece ser peer to peer, mas o que isso significa no contexto de placas de vídeo?
https://developer.nvidia.com/gpudirect
Eu gostaria que mais empresas de hardware abrissem a documentação e deixassem a comunidade descobrir o restante
É parecido com o que aconteceu com o IBM VGA inicial. O “Mode X” ou os modos reais do hardware, que não eram do BIOS, até mesmo 800x600x16, bastava procurar para encontrar. Infelizmente, a maioria parece preferir controlar rigidamente todos os aspectos do uso do produto para extrair mais dinheiro da base de usuários. Pessoalmente, acho que a época em que os PCs foram mais produtivos também foi a época em que eram mais abertos
Então o preço do produto simplesmente ficaria mais caro
A interoperabilidade adversarial era comum, e as pessoas faziam software funcionar por engenharia reversa, quer o fabricante quisesse ou não. O que antes era raro, mas hoje se tornou comum, são bloqueios de software e hardware. A criptografia deveria ser uma tecnologia que nos desse poder, mas acabou sendo usada para nos excluir das nossas próprias máquinas. Agora não estamos mais no banco do motorista. Nem mesmo o sistema operacional consegue mais operar o sistema de fato. Mesmo um sistema Linux livre é apenas um “SO de usuário” dentro de um amontoado feito de firmware proprietário e silício desconhecidos pelo fabricante, mais parecido com uma pequena peça colocada em sandbox em relação ao funcionamento real
A justificativa original que a Nvidia deu ao remover o NVLink da linha de consumo foi que o PCIe 5 seria rápido o bastante
Mas a série 40xx foi lançada sem PCIe 5 e sem suporte a P2P. É bom que agora ao menos metade dessa promessa esteja sendo cumprida, mas é difícil imaginar que eles permitirão isso também no firmware da próxima geração
Este é um daqueles recursos desativados em placas de consumo para segmentação de mercado?
Fazendo uma analogia imperfeita, imagine um pequeno bairro com umas 15 casas em construção. Normalmente, colocariam um transformador de 200 kVA na esquina e forneceriam a energia adequada pela rede elétrica. Mas, por falta de transformadores, a construtora instala um transformador comercial de 1250 kVA. Ele consegue alimentar muito mais casas do que o necessário, então opera com bastante capacidade sobrando. Um dia, um morador decide que quer começar uma grande plantação e descobre uma forma de ativar só para a casa dele aquela capacidade excedente do transformador. O que o geohot encontrou corresponde justamente a essa "ativação"
Há muito tempo sempre me impressiono com a habilidade de hacking do George Hotz. Ela também foi uma grande inspiração para meus projetos pessoais
Ele frequentemente trava em problemas superficiais e arbitrários que pareceriam menos difíceis para um engenheiro com mais conhecimento. Também é comum vê-lo escrevendo código realmente ruim, ou até código errado. As cenas relacionadas ao Twitter são um bom exemplo. Mesmo assim, trabalhando sozinho e insistindo repetidamente, ele consegue com a mesma frequência produzir melhorias surpreendentes. É um bom exemplo do qual aprender
Parabéns ao geohot e a todos os colaboradores do tinygrad/comma
Dei uma passada pelo README e, para quem estiver curioso, isto é P2P sobre PCIe, não NVLink
Nas arquiteturas futuras, eles vão começar a bloquear isso no firmware, então será bom enquanto durar
Então é melhor poder usar por pelo menos uma geração do que não ter nada
Fico curioso se foi o próprio George que fez isso, ou se foi alguém interessado na recompensa que a tinycorp tinha oferecido
E, para quem conhece bem o subsistema PCI: isso não parece mais algo em que a NVIDIA simplesmente não prestou atenção, em vez de algo que ela tentou bloquear ativamente?
Então faz sentido mexer no dispositivo e configurá-lo para colocar toda a VRAM no espaço de endereçamento. Basta haver suporte a resizable BAR, ou uma BAR de tamanho fixo grande o suficiente. Também faz sentido instruir uma placa a ler e escrever em endereços mapeados para a VRAM de outra placa. Fico curioso se o gargalo será a capacidade de comutação do PCIe, ou os links ponto a ponto e a VRAM. De qualquer forma, reduzir a ida e volta pela RAM do sistema deve ajudar