nvidia-open: переходить на открытый модуль или нет?

25.09.2026 · ~7 минут чтения

Telegram · @linux4at Max · Присоединиться

nvidia-open — открытая ветка модуля ядра NVIDIA, а не новая видеокарта и не полностью открытый драйвер. Переход оправдан на Turing и более новых GPU с актуальным ядром, если открытая ветка поддерживает нужные функции. Pascal, Maxwell и ноутбучные конфигурации Optimus чаще разумнее оставить на проприетарном модуле, особенно после анонса ветки 590 о снятии поддержки Pascal.

Что такое nvidia-open и чем он отличается от nvidia?

У драйвера NVIDIA есть два варианта модуля ядра. Закрытый вариант nvidia поставляется как проприетарный бинарный модуль. Вариант nvidia-open заменяет только модуль ядра на открытую реализацию, а библиотеки userspace, утилиты, CUDA и firmware остаются проприетарными. Поэтому слово open не означает, что весь драйвер стал свободным или что скорость вырастет безусловно.

В Arch пакеты названия nvidia и nvidia-open подходят для штатного ядра. Для собственного ядра или LTS-версии обычно нужен вариант *-dkms либо пакет, собранный под конкретную версию ядра. Одновременно держать закрытый и открытый модули нельзя: они занимают один и тот же слот nvidia.ko и конфликтуют при загрузке.

Открытая ветка интересна там, где производитель активнее переносит новые GPU и kernel API в открытый код. Но список поддерживаемых чипов, версии CUDA и набор функций меняются от выпуска к выпуску. Решение принимай для конкретной карты, ядра и сценария работы, а не только по названию пакета.

Что значит снятие поддержки Pascal в ветке 590?

В 2026 году ветка NVIDIA 590 объявляет снятие поддержки Pascal — поколения GTX 10xx и родственных архитектур. Для новой карты это почти не заметно, а для владельца старого GPU меняется план обновлений: новые исправления и возможности могут больше не приходить, и переход на свежий релиз Arch может оставить систему без рабочего драйвера.

Снятие поддержки не означает, что Pascal мгновенно перестанет работать. Старый проприетарный модуль и подходящая версия драйвера продолжат выполнять задачи. Но если репозиторий перешёл на 590, а твоя карта не входит в список чипов этой ветки, обновление nvidia не спасёт. Открытая ветка из той же линейки также не станет универсальной заменой: если поддержка Pascal убрана на уровне драйвера, смена open на closed её не вернёт.

Для Pascal практичный путь — удерживать проверенную версию драйвера и LTS-ядро, пока не появится подходящая ветка. Выбор ядра и порядок его обновления описаны в статье про выбор Linux-ядра. Для Maxwell и других старых поколений действует тот же осторожный подход.

Почему возникает рассинхрон версий с ядром?

Модуль nvidia.ko компилируется или собирается под конкретную версию ядра. После обновления ядра старый модуль может не загрузиться, даже если пакет драйвера формально установлен. С DKMS добавляется ещё один слой: сборка должна пройти после обновления, а заголовки ядра и версии компилятора обязаны совпадать.

Рассинхрон выглядит по-разному. Прерванная транзакция pacman оставляет новую библиотеку и старый модуль. Переустановка ядра без mkinitcpio оставляет initramfs со старым модулем. Обновление только nvidia-utils без ветки nvidia создаёт несовпадение userspace и ядра. Иногда модуль собирается, но открытая ветка не поддерживает конфигурацию GPU или нужную функцию.

Типичные сообщения в журнале — version mismatch, API mismatch, Failed to initialize NVML, NVRM: Xid или ошибка загрузки nvidia.ko. Чёрный экран после такого обновления — один из симптомов, а не отдельный диагноз.

Как понять, какая ветка стоит, и исправить рассинхрон?

Сначала сравни активное ядро, установленные пакеты и файл модуля. Команды выполняй в работающей системе или в tty, полученном через временный nomodeset:

uname -r
pacman -Q | grep -E '^(nvidia|linux)'
pacman -Qo "$(modinfo -n nvidia 2>/dev/null)"
modinfo -F version nvidia
dkms status
lspci -nnk | grep -A3 -Ei 'VGA|3D|Display'

pacman -Qo покажет, какой пакет владеет загруженным модулем, а dkms status — собрал ли его DKMS. Если modinfo не находит файл, сначала проверь initramfs и заголовки ядра, а не переустанавливай пакет наугад.

Для возврата к рабочему состоянию выбери одну ветку. Для штатного ядра замени закрытый пакет открытым:

sudo pacman -Rns nvidia
sudo pacman -S nvidia-open
sudo mkinitcpio -P

Для DKMS используй связку nvidia-dkms → nvidia-open-dkms и установи linux-headers для активного ядра. Не удаляй nvidia-utils, пока он нужен выбранной ветке. После перезагрузки проверь nvidia-smi и журнал:

nvidia-smi
sudo journalctl -b -k | grep -Ei 'nvidia|drm|nvrm|version mismatch|api mismatch'

Если nomodeset помог только попасть в tty, это подтверждает аварию графического стека, но не решает рассинхрон. Подробная последовательность спасения описана в статье про чёрный экран и nomodeset.

Когда переходить, а когда оставаться на проприетарной ветке?

Переходи на nvidia-open, если у тебя Turing или новее, включая RTX 20xx и последующие поколения, а выбранная версия драйвера поддерживает карту и нужные kernel API. Такой переход особенно разумен на свежем ядре, когда производитель уже переносит туда новые GPU и исправления. Сначала проверь, что открытая ветка поддерживает нужные CUDA-приложения, Wayland, suspend и подключение внешних мониторов.

Оставайся на nvidia, если у тебя Pascal GTX 10xx, Maxwell или другая карта вне списка поддержки. Не переводи на новую ветку 590 карту, для которой эта линейка уже не имеет поддержки. На ноутбучных Optimus-конфигурациях осторожность оправдана: открытый модуль может иначе вести себя с гибридной графикой, suspend и переключением дисплеев, даже если основной сценарий выглядит рабочим.

Рабочая машина с LTS- или hardened-ядром — ещё один повод не менять ветку без проверки. Открытый модуль не даёт автоматического ускорения, зато добавляет миграцию, пересборку DKMS и новый журнал ошибок. Если текущая проприетарная ветка стабильна, разумнее дождаться ясного выигрыша.

Как перейти без простоя и как откатиться?

Сначала запиши состояние, чтобы не потерять рабочую конфигурацию:

pacman -Q | grep -E '^(nvidia|linux)'
modinfo -n nvidia
lspci -nnk

Заверши графическую сессию, загрузись в tty и удали только закрытый модуль. Для штатного ядра:

sudo pacman -Rns nvidia
sudo pacman -S nvidia-open
sudo mkinitcpio -P

Для DKMS повтори ту же схему с nvidia-dkms и nvidia-open-dkms. Не запускай обе команды подряд без проверки: сначала убедись, что активный пакет действительно конфликтует. После перезагрузки сверь pacman -Qo "$(modinfo -n nvidia)" и nvidia-smi.

Если во время планового обновления нельзя получить версию, совместимую с картой, временно добавь в секцию [options] файла /etc/pacman.conf строку:

IgnorePkg = nvidia

Это способ удержать один пакет, а не универсальное решение. Он опасен для rolling-системы: ядро и зависимости могут уйти вперёд, а игнорирование одного пакета способно оставить частичное обновление. Для Pascal используй задержку только вместе с проверенным LTS-ядром, затем верни строку, когда появится подходящая ветка.

Откат к закрытой ветке выглядит так:

sudo pacman -Rns nvidia-open
sudo pacman -S nvidia
sudo mkinitcpio -P

Для отката версии открытой ветки помогает downgrade:

sudo pacman -S downgrade
downgrade nvidia-open

После любого отката проверь журнал и загрузку без nomodeset. Если графический стек исправен, но чёрный экран появляется только в Wayland, различай ошибку драйвера и ошибку compositor; разница описана в статье про включение Wayland.

Частые вопросы

nvidia-open всегда быстрее nvidia?

Нет. Разница в производительности зависит от GPU, версии драйвера, ядра и сценария. Часто приложения используют один и тот же userspace, поэтому переход сам по себе не даёт гарантированного ускорения. Сравнивай производительность на своей карте и не меняй ветку только ради цифры в описании пакета.

Можно ли установить nvidia и nvidia-open вместе?

Нет. Пакеты конфликтуют за модуль ядра, initramfs и последовательность загрузки. Сначала удали старую ветку, затем установи новую и пересобери initramfs. nvidia-utils может остаться общей зависимостью, но его нельзя считать заменой модулю.

Что делать, если nvidia-smi работает, а графика не запускается?

Скорее всего, модуль и userspace исправны, а проблема лежит в display manager, compositor или конфигурации сессии. Проверь journalctl -b -u display-manager и активный графический сервер. Переустановка драйвера в таком случае не нужна, если нет ошибок в nvidia-smi.

Поддерживает ли nvidia-open Pascal?

Зависит от версии ветки. Для релизов до снятия поддержки проверяй список чипов NVIDIA и ArchWiki. В ветке 590, где Pascal снят с поддержки, ни открытый, ни закрытый модуль этой линейки не стоит считать рабочим решением для такой карты.

Полезные ресурсы

Заключение

Рассинхрон nvidia-open с ядром решается не сменой названия пакета, а проверкой версии, модуля и ветки драйвера. На Turing и новее переход обычно безопасен после проверки функций, а Pascal, Maxwell и Optimus лучше оставить на проприетарной ветке с совместимым ядром. Перед переходом сохрани рабочую версию и проверь nvidia-smi после каждого изменения.

Не получилось? Поможем настроить

Задай вопрос в чате — отвечаем быстро, по делу и без воды.