How to install nvidia drivers

Introduction

This page and linked articles present the status and directions of low-level components with which FreeBSD becomes a basis for desktop environments (DEs) such as KDE Plasma and Gnome.

This level includes:

X.Org-related ports: xserver, libraries, tools
Future Wayland-related ports
Mesa ports: libGL, dri, libglesv2, libEGL, freeglut, libGLU, libGLw, mesa-demos, libosmesa
OpenCL low-level libraries
Userland drivers (ie. xf86-*)
Input devices detection and configuration
Kernel-side GPU drivers (i.e. drm-* kernel modules)

This level does not include:

The DEs
Image processing or drawing software applications.

Contents

Other pages in this namespace:

Development

Developer information, including tasks in progress and similar, is available in the developer section.

TODO

Tasks available to contributers

Task	Developer	Status	Comment
Get Intel GPU Tools working		Initial port exists	Outdated initial port here

Team Members

who	area of responsibility/knowledge
zeising@	Everything ports related, team meetings, etc.
manu@	mesa, drm drivers
bapt@	ports, a bit of everything
imp@	core liason, contact him before committing maintainer timeouts
jkim@	ports, member emeritus
kwm@	ports, member emeritus
miwi@	ports, member emeritus

Mailing List: freebsd-x11
IRC: #freebsd-xorg (EFnet)
Gitter: https://gitter.im/FreeBSDDesktop/Lobby
GitHub: FreebsdDesktop Organization Repositories

Hardware Support

The tables below are not an exhaustive list of supported hardware. Hardware is only listed if and when it has been explicitly tested/confirmed by developers and/or users. Graphics hardware missing from these tables may or may not work. If you have tested hardware that is not on the list, please .

About GPU codenames vs. marketing names

The entries below are misleading because they use the marketing names as the «key». This table needs to be rewritten using GPU codenames as the key.

If your GPU is not supported

If your GPU is not supported by FreeBSD, you can fallback to VESA (if your computer uses a BIOS) or SCFB (if your computer uses UEFI). For the latter case, you can find instructions to setup SCFB in a dedicated article.

drm-kmod

graphics/drm-kmod indirectly provides a range of kernel modules for use with Intel Integrated Graphics and AMD graphics hardware.

Associated code is actively developed and allows us to track, more closely, drivers in the Linux kernel.

Intel Integrated Graphics (aka HD Graphics)

Intel HD Graphics refers to the class of graphics chips that are integrated on the same die as an Intel CPU. Wikipedia offers a good overview of the variations and names used for generations of Intel HD Graphics. Intel HD Graphics chips are found in many modern laptop and desktop systems that ship with an Intel CPU. Commonly-found configurations include Kabylake Intel i915 HD Graphics.

To enable the integrated graphics chip on Intel CPUs, install drm-kmod. The resulting module should work well on all compatible systems.

This page includes a table of states for various Intel chipsets.

If you notice high CPU usage, or excessive tearing with HD video: multimedia/libva-intel-driver may help – installation should be in addition to drm-kmod, mesa-libs and mesa-dri.

Example configuration:

Install the graphics/drm-kmod package
# pkg install drm-kmod
The post-installation message presents essential information. With FreeBSD 13⋯, this command will safely configure your /etc/rc.conf:

# sysrc -f /etc/rc.conf kld_list+=i915kms
Ensure that your UID is a member of the video group.
Restart your system. You should see i915kms listed, and a flash of the console when the display driver is switched.
Start X.Org via your usual method (i.e. startx, GDM, etc.)

In most cases:

Manual configuration of X.Org is not required
x11-drivers/xf86-video-intel is optional

– X.Org should autodetect the driver, and utilize the modesetting X.Org driver and glamor driver.

AMD Graphics

Unlike the i915 Intel graphics driver, two modules exist for AMD hardware:

amdgpu
radeonkms

– choose one, based on the generation of the hardware.

In most cases:

Manual configuration of X.Org is not required.

We have an AMD graphics support matrix. The X.Org project provides a .

If UEFI boot results in a conflict between a driver and the EFI frame buffer, you can add this line to /boot/loader.conf to disable the buffer:

hw.syscons.disable=1

With the buffer disabled, console output will not appear until the driver loads. https://github.com/FreeBSDDesktop/DEPRECATED-freebsd-base-graphics/issues/170 explains.

AMD GPU

The amdgpu module is for post-HD7000 or Tahiti GPUs.

Install the graphics/drm-kmod package
# pkg install drm-kmod
The post-installation message presents essential information. With FreeBSD 13⋯, this command will safely configure your /etc/rc.conf:

# sysrc -f /etc/rc.conf kld_list+=amdgpu
Ensure that your UID is a member of the video group.
Restart your system. You should see amdgpu listed, and a flash of the console when the display driver is switched.
Start X.Org via your usual method (i.e. startx, GDM, etc.)

Radeon KMS (kernel mode setting)

The radeonkms module is for older GPUs (pre-HD7000 or pre-Tahiti).

Install the graphics/drm-kmod package
# pkg install drm-kmod
The post-installation message presents essential information. With FreeBSD 13⋯, this command will safely configure your /etc/rc.conf:

# sysrc -f /etc/rc.conf kld_list+=radeonkms
Ensure that your UID is a member of the video group.
Restart your system. You should see radeonkms listed, and a flash of the console when the display driver is switched.
Start X.Org via your usual method (i.e. startx, GDM, etc.)

Virtual Machines

VMware

Experimental support for accelerated graphics in FreeBSD as guest OS in VMware was added to graphics/drm-devel-kmod.

Known issue:

A race condition in which the machine locks when loading the graphics driver or starting X. Observable only if the guest is configured with more than one CPU.

A DRM driver for VirtualBox is planned for the Linux source tree. Once there, a FreeBSD port is planned.

Установка драйверов Nvidia

1. Узнаем необходимую версию драйвера

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

Чтобы узнать номер модели используйте команду lspci:

По сути, нужно выбрать серию, модель и операционную систему, язык по желанию

Обратите внимание на параметр Download Type. С помощью него можно указать какая версия драйвера вам нужна — стабильная или самая новая

Для получения стабильной версии выберите Production Branch. Далее нажмите кнопку Search. На открывшейся странице вы увидите рекомендуемую версию драйвера:

Для GeForce 780 — это 470.88. В то же время самая последняя версия драйвер — 495. Для более старых видеокарт, версия драйвера может быть ещё более давней, например, для GeForce 440 рекомендуемый драйвер — 390.144:

Теперь мы знаем какой драйвер, нужен, уже на этом этапе можно скачать установочный пакет и переходить к установке, но мы поступим по-другому. Дальше будет рассмотрена установка драйвера Nvidia в Ubuntu 20.04 из репозитория PPA.

2. Установка драйвера из официальных репозиториев

В Ubuntu 20.04 для управления драйверами оборудования используется утилита ubuntu-drivers. Конечно, мы можем как и раньше использовать apt, но я думаю, что так намного удобнее. Давайте посмотрим какую версию драйвера посоветует нам установить утилита:

Программа предлагает версию 470. Однако не всегда самая свежая версия доступа по умолчанию. Если вас устраивает эта версия, ее можно установить командой:

Также можно установить эту же версию с помощью apt:

Но если вы хотите самую новую версию, в данном случае 495, то надо использовать PPA.

2. Установка из PPA репозитория

Репозиторий graphics-drivers содержит самые последние версии драйверов nvidia. Его мы и будем использовать для установки. Для добавления graphics-drivers в систему, выполните команды

Теперь PPA репозиторий добавлен и списки пакетов обновлены, можно переходить к установке. Запустите еще раз утилиту ubuntu-drivers:

Теперь утилита будет видеть самую новую версию драйвера — 495 если, конечно, ваша видеокарта его поддерживает, а также 470, которую ранее советовали установить на официальном сайте. Кроме того, вы можете убедится, что эта версия драйвера есть в репозиториях с помощью такой команды:

Для установки версии 495 используйте команду apt:

После завершения установки перезагрузите компьютер.

3. Установка драйверов Nvidia с помощью GUI

Если не хотите пользоваться консолью, можете включить драйвер с помощью утилиты Программы и обновления. Откройте главное меню Gnome и наберите в поиске Программы:

Запустите утилиту и перейдите на вкладку Драйверы:

Утилита видит те же самые драйвера из репозиториев, что и ubuntu-drivers. Просто выберите нужную версию драйвера и нажмите кнопку Применить изменения.

После завершения установки обязательно перезагрузите компьютер. В меню появиться ярлык утилиты Nvidia Settings, с помощью нее вы можете посмотреть характеристики видеокарты, а также настроить кое-какие параметры.

4. Установка из официального сайта

Это самый сложный вариант установки, поэтому если вы новичок, вам лучше использовать репозитории. Сначала загрузите официальный бинарный файл с драйвер со страницы на шаге 1. Там есть кнопка Загрузить сейчас. После её нажатия должно открыться ещё одно окно, в котором необходимо снова нажать Загрузить сейчас:

В итоге, в вашей папке загрузок должен появится такой файл:

Теперь необходимо добавить поддержку архитектуры i386 и установить библиотеку libc6 чтобы не получить проблем во время установки:

Устанавливать драйвер можно только из консоли. Если в момент установки будет запущен графический сервер, то ничего хорошего из этого не получится, вы просто не сможете потом загрузится в систему. Поэтому переключитесь во второй терминал сочетанием клавиш Ctrl+Alt+F2 и введите там свой логин и пароль. Затем выполните такую команду для остановки графического сервера:

Теперь можно переходить к установке. Запустите установочный скрипт командой:

Затем вам нужно будет принять лицензию и дождаться завершения установки. После чего можно перезагрузить компьютер такой командой:

Если установка nvidia ubuntu 18.04 прошла успешно, вы загрузитесь уже с новым драйвером.

Reporting

Issues / Bugs

dmesg command output
pciconf -lvbce command output
devinfo -vr command output
sysctl hw.model
pkg info command output
Contents of xorg.conf file (and included sub-files, if any)
Contents of Xorg.log (if the problem is at X.Org startup or during your X session)
Any ports build or installation errors (if relevant)
If a kernel panic: Contents of core.$n.txt (in /var/crash)
Any other details that may be relevant

Debugging Tips

It is useful to see what features the kernel reports as being available, especially in regards to driver features exposed via the linuxkpi. On FreeBSD these are mapped to sysctl compat.linuxkpi. The best way to see what’s available for your driver is to execute sysctl compat.linuxkpi after you loaded the driver. For description of what these parameters do, call sysctl with the description flag.
% sysctl -d compat.linuxkpi.enable_fbc
compat.linuxkpi.enable_fbc: Enable frame buffer compression for power savings (default: -1 (use per-chip default))

Starting with FreeBSD 13 you can use the direct driver sysctls, the compat.linuxkpi will be removed at one point.
% sysctl -d hw.i915kms
Periodically you will have a kernel panic but a core will not be recorded. You can test setting this sysctl knob which will prevent you from entering ddb on panic which has been found to unreliable in some circumstances:
debug.debugger_on_panic=0
Also, adding this to your /boot/loader.conf can help in these scenarios:
dev.drm.skip_ddb=»1″
The following can be useful for providing context and can be set in /boot/loader.conf to ensure debug output remains enabled. The one problem with it is that debug output will slow things down enough to mask many problems.:
dev.drm.drm_debug_persist=»1″
Want to enable all DRM related debug flags at runtime? There is a knob for that:
dev.drm.drm_debug=-1
kms drivers through linux-kpi report debugging information using debugfs. To mount it:
# mkdir /debug && mount -t debugfs none /debug
To test how hardware acceleration is working you may want to run glxgears, but by default it may force syncing with your display (60fps for example). To disable this you can invoke glxgears like so:

$ env vblank_mode=0 glxgears

Test Results

Please include:

dmesg command output
pciconf -lvbce command output
pkg info command output
Contents of xorg.conf file (and included sub-files, if any)
Contents of Xorg.log
Any other details that may be relevant

If your laptop works well with FreeBSD, add it to the Laptops page.

Preferred Policies on Patches

In the past, the FreeBSD graphics stack got far behind the upstream sources. One of the main reasons for this was that as a project we’d been terrible about getting changes accepted upstream (or even trying to upstream them). These technical issues lead to much frustration and exacerbated many teamwork issues with the stack. For a time, things were somewhat dysfunctional. However, the graphics teams has caught up on all this technical debt by upstreaming changes; integrating Linux compatible APIs (like evdev); or by writing adapters to make FreeBSD-specific things like devd look like their Linux counterparts.

To avoid a repeat of this accumulation of technical debt, and all the issues that go with it, the graphics teams has a number of preferred practices it likes to follow. Generally we prefer using released versions of the elements of FreeBSD graphics stack. Issues come up between releases, and if the patches are accepted by upstream, then we’ll include them. When there are issues that are being sorted out upstream, we prefer to let that run its course because they are usually the experts, though exceptions are made when reasonable. At the very least, we’d like any patches submitted upstream before they are included in a port to strongly encouraging upstreaming. Finally, when new features are implemented, there’s a strong preference for using Linux and other APIs upstream sources are using over inventing something new for FreeBSD where possible.

We also desire to have FreeBSD be in the CI process for as many upstream sources as possible, though currently many do not yet have FreeBSD CI support. Helping upstreams get better CI integration will help us maintain the velocity of releases as FreeBSD is more likely to work and needs less regression testing on updates by us.

CategoryProject CategoryTeam CategoryPorts

Known Issues

Permission errors, or inability to start X when using the DRM kernel modules? Make sure your user is a member of the video group, otherwise you will not have access to /dev/drm/ devices.
Xorg -configure crashes with a «Segmentation fault»; it is a known defect. Do not use Xorg -configure anymore: it is recommended to let Xorg auto-configure itself. If you need to override part of the configuration, create a config file under /usr/local/etc/X11/xorg.conf.d/ containing only the relevant section.
There are reports that users on i386 hardware have problems using the drm-kmod package. A workaround for this is to disable PAE via /boot/loader.conf: hw.above4g_allow=0