Linux 7.3 melhora o desempenho ao ficar sem VRAM
O kernel Linux 7.3 introduz novo gerenciamento de VRAM que melhora bastante o desempenho quando as GPUs ficam sem memória de vídeo, especialmente para jogos e cargas gráficas pesadas. Comentadores comparam isso ao comportamento do Windows e do macOS sob pressão de memória, debatendo overcommit, swap e OOM killing, e observando que o Linux frequentemente ainda congela ou mata aplicativos aleatoriamente, a menos que seja ajustado com ferramentas como earlyoom ou systemd-oomd. O debate também destaca problemas de longa data com os drivers Linux da Nvidia em comparação com o fallback mais transparente entre VRAM e RAM do sistema na AMD, além de preocupações mais amplas com vazamentos de memória, responsividade da área de trabalho e como plataformas diferentes priorizam estabilidade versus flexibilidade.
Reação Geral ao Trabalho no Kernel
- O artigo é elogiado como uma engenharia de kernel clara e detalhada, com ferramentas de tracing úteis (por exemplo, gpuvis, tracepoints do DRM).
- Muitos demonstram entusiasmo com o foco do Linux 7.2/7.3 em jogos e desempenho de GPU.
- Alguns destacam que um bom comportamento da VRAM, no fim das contas, é limitado pelo projeto do hardware (por exemplo, scanout usando apenas endereços físicos).
Jogos, Overcommit de VRAM e Desperdício de Assets
- Há grande interesse em como as melhorias de overcommit de VRAM ajudam jogos com muitas texturas e que frequentemente desperdiçam VRAM com assets grandes demais ou não usados.
- Comentadores apontam exemplos reais de texturas enormes e desnecessárias, e jogos lançados com desperdício massivo de memória.
- Alguns se perguntam se o kernel poderia sempre reservar regiões contíguas de scanout ou “desfragmentar” fisicamente a VRAM movendo páginas e atualizando tabelas de páginas; a viabilidade permanece incerta.
Compute / LLM e Ideias de VRAM–Disco
- Para inferência de LLM, a maioria espera pouco benefício: as cargas de trabalho são mais previsíveis e podem gerenciar manualmente a memória da GPU.
- A ideia de mover dados da GPU para NVMe como “swap de VRAM” é discutida; no melhor caso, seria cerca de 4× mais lento devido aos limites de lanes PCIe, então apenas casos de uso de nicho parecem plausíveis.
Linux vs Windows/macOS e a Experiência de GPU/Área de Trabalho
- Muitos celebram as rápidas melhorias no kernel Linux; outros apontam regressões (por exemplo, um escalonador de GPU revertido) e quebras específicas de distribuições, especialmente em distros rolling.
- O Windows recebe crédito por HDR/VRR e suporte a eGPU mais maduros; o Linux é visto como estando a alcançar, mas não como universalmente superior.
- O Apple Silicon/macOS recebe avaliações mistas: boa UI de OOM e comportamento de memória unificada para alguns, mas outros relatam lentidões persistentes após uso intenso de ML/GPU.
Tratamento de VRAM: NVIDIA vs AMD e Wayland
- Vários relatos dizem que GPUs AMD no Linux fazem spill para a RAM do sistema de forma transparente quando a VRAM enche, enquanto a NVIDIA no Linux+Wayland historicamente travava ou recusava alocações quando a VRAM se esgotava.
- Bugs de longa data nos drivers da NVIDIA no Wayland (por exemplo, vazamentos de memória com KWin, ausência de “shared VRAM”) são mencionados; muitos concluem que a AMD é atualmente a escolha mais segura no Linux, especialmente para Wayland e jogos.
Comportamento de OOM, Swap e Ajustes
- Há um longo subthread sobre o Linux congelar sob pressão de RAM, enquanto Windows/macOS permanecem lentos, mas vivos.
- As explicações giram em torno do overcommit do Linux e do OOM killing heurístico, versus o modelo de alocação mais estrito do Windows.
- Mitigações mencionadas: swap/zswap/zram, ajuste do MGLRU, earlyoom/systemd-oomd/nohang, configurações de overcommit.
- As opiniões divergem fortemente: alguns dizem “configurado direito, o Linux fica bem”, outros chamam o comportamento padrão de OOM na área de trabalho de um problema antigo e hostil ao usuário.
Diversos
- Esclarecimento de que “VRAM” (não “vRAM”) é o uso padrão; “vRAM” sugere “virtual RAM”.
- Breve nota valorizando contribuições de grupos sub-representados em engenharia de desempenho de baixo nível.