Линукс Док

Проверка GPU и видеоускорения

Графика

Автор: Летописец, Дата: 2026-10-26

Диагностика графики почти всегда идёт по одному сценарию: сначала выяснить, на каком этаже проблема, потом смотреть именно там. Ниже — команды, которые дают ответ за пару минут, и таблица «симптом → куда смотреть».

Пять команд, которые отвечают на главный вопрос

# 1. Кто управляет железом
$ lspci -k | grep -A3 -E 'VGA|3D'

# 2. Работает ли GPU или всё на процессоре
$ glxinfo -B | grep -E 'OpenGL renderer|OpenGL version'

# 3. Видео: что умеет железо декодировать
$ vainfo | head -20

# 4. Мониторы и режимы
$ xrandr --listmonitors

# 5. Что сказало ядро
$ journalctl -k | grep -iE 'i915|drm|firmware' | head -20

Как читать результат:

Вывод Что значит
Kernel driver in use: i915 Драйвер ядра взял устройство
OpenGL renderer: Mesa Intel(R) Graphics (…) Рендеринг на GPU
OpenGL renderer: llvmpipe Рендеринг на процессоре — ускорения нет
vainfo перечисляет профили (H264, HEVC, VP9…) Железо умеет декодировать видео
vainfo: Driver version: … и пустой список Драйвер VA-API есть, но профилей нет — обычно не тот драйвер
В журнале firmware: failed to load Нет прошивки (GuC/HuC) — часть возможностей отключится

llvmpipe в рендерере — самый частый «тихий» сбой: картинка есть, ошибок нет, но всё рисует процессор. Причины: пользователь без доступа к /dev/dri, загружено ядро с nomodeset, отсутствует пакет Mesa для Intel.

Видео: проверить, что декодирует железо

vainfo показывает возможности, но не факт, что они используются. Проверить по-настоящему — по нагрузке на GPU:

# в одном окне: смотрим движки GPU
$ sudo intel_gpu_top

# в другом: играем видео с аппаратным декодированием
$ mpv --hwdec=auto видео.mkv

В intel_gpu_top есть строки движков: Render, Video, VideoEnhance. Если во время воспроизведения Video заметно загружен — декодирует железо. Если он стоит на нуле, а процессор занят — декодирование идёт на CPU, и видео будет греться и дёргаться.

В браузере это видно на странице chrome://gpu (или about:support в Firefox): строка «Video Decode» должна говорить об аппаратном ускорении.

Если vainfo профилей не показывает, проверьте, какой драйвер установлен: для новых Intel нужен iHD (intel-media-driver в RPM-семействах, intel-media-va-driver в Debian/Ubuntu), а не старый i965.

Живой пример: нашли поломку и починили

На этой машине аппаратное декодирование не работало. Вот как это выглядело:

$ vainfo
libva info: VA-API version 1.23.0
libva info: Trying to open …/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open …/dri/i965_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error)

Причина: libva установлена (1.23.0), но драйверов Intel для неё нет — в каталоге dri/ были *_drv_video.so для AMD и virtio, а iHD и i965 отсутствовали.

Лечение:

$ sudo apt install intel-media-va-driver      # iHD — основной драйвер для Intel Gen8+

После установки — тот же vainfo, и картина другая:

$ vainfo | head -8
libva info: Trying to open …/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.23 (libva 2.22.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 26.1.2

$ vainfo | grep -c VAEntrypointVLD     # профилей декодирования
11

Что теперь умеет железо:

Профиль Декодирование Кодирование
H.264 (Main, High, Constrained Baseline) да да (EncSliceLP)
HEVC (Main, Main10) да —
VP9 (Profile 0, 2) да —
VP8, MPEG-2 да —
JPEG да да (EncPicture)

AV1 в списке нет — и это не поломка: UHD 620 относится к поколению Gen9.5, а аппаратное декодирование AV1 появилось только с Gen12 (Tiger Lake). Поэтому AV1-видео на этой машине будет декодироваться процессором, и это нормально.

Практический вывод: vainfo — первая команда при «видео тормозит», и её вывод нужно читать буквально. returns -1 — драйвера нет; returns 0 и список профилей — есть.

Как проверить в браузере

Драйвер установлен — ещё не значит, что приложение им пользуется. У Chromium-браузеров (Chrome, Яндекс Браузер, Edge) проверка такая: открыть chrome://gpu и смотреть две разные вещи:

  1. Graphics Feature Status — включена ли функция вообще. Строка Video Decode: Hardware accelerated значит «функция разрешена», а не «декодер работает».
  2. Video Acceleration Information — что инициализировалось на самом деле. Смотреть надо не на заголовок Decoding : (он пустой всегда), а на строки под ним — Decode h264, Decode vp9 и так далее. Если строк Decode … нет вовсе — декодера нет, даже при «Hardware accelerated» выше.

Вот настоящий экспорт chrome://gpu с этой машины, сделанный после установки драйвера, но без перезапуска браузера:

Video Decode: Hardware accelerated          ← функция включена
Video Acceleration Information
Decoding:                                    ← пусто: декодера нет
Encoding:
...
[ERROR:vaapi_wrapper.cc:1796] : vaInitialize failed: unknown libva error

То есть «зелёная» строка статуса и отсутствие строк Decode … — не противоречие: смотреть надо во второе место.

И объяснение, почему пусто, хотя драйвер уже стоит: браузер не перезапускался. В том же экспорте ошибка vaInitialize failed датирована 24.10 21:19 — ровно тем временем, когда стартовал процесс браузера (ps -eo pid,lstart подтверждает: 24.10 21:19:57). Chromium инициализирует VA-API один раз, при старте GPU-процесса, и живёт с этим результатом, пока его не перезапустят. Драйвер поставили — браузер об этом не знает.

А вот тот же экспорт после полного перезапуска браузера — декодирование заработало:

Video Acceleration Information
Decoding                      :
Decode h264 baseline          : 16x16 to 4096x4096 pixels
Decode h264 main              : 16x16 to 4096x4096 pixels
Decode h264 high              : 16x16 to 4096x4096 pixels
Decode vp8                    : 16x16 to 4096x4096 pixels
Decode vp9 profile0           : 16x16 to 8192x8192 pixels
Decode vp9 profile2           : 16x16 to 8192x8192 pixels
Decode hevc main              : 16x16 to 8192x8192 pixels
Decode hevc main 10           : 16x16 to 8192x8192 pixels
Decode hevc main still-picture: 16x16 to 8192x8192 pixels
Encoding                      :

Что видно:

  • H.264, VP8, VP9 и HEVC декодируются железом, HEVC и VP9 — до 8192×8192;
  • AV1 нет — нормально для Gen9.5: аппаратное декодирование AV1 появилось только с Gen12 (Tiger Lake), так что AV1-видео на этой машине всегда будет идти через процессор;
  • Encoding пуст — браузер не использует аппаратное кодирование; это штатно, а не поломка;
  • ошибка vaInitialize из журнала исчезла, остались только eglCreateContext: Requested version is not supported — это шум инициализации ANGLE, к видеоускорению отношения не имеет.

Ещё две строки из того же экспорта полезны для общего понимания:

  • GPU0: VENDOR=0x8086, DEVICE=0x3ea0, DRIVER_VENDOR=Mesa, DRIVER_VERSION=26.0.8 — тот же 0x3ea0, что и в журнале ядра, и та же Mesa;
  • Display bounds=[0,0 1600x900], scale=1 — браузер видит логические 1600×900 при панели 1920×1080, то есть 125 % масштабирования (см. X11 и Wayland).

После установки драйвера браузер нужно перезапустить: VA-API инициализируется один раз, при старте GPU-процесса. Потом — снова chrome://gpu и смотреть Decoding:.

В Firefox проверка другая: about:support → «Media»; там же параметр media.ffmpeg.vaapi.enabled.

Сколько это стоит по счётчикам

Проиграли тестовый ролик 1080p30 (20 секунд) и снимали intel_gpu_top раз в секунду — 73 секунды записи:

Движок Среднее за запись В секунды воспроизведения
Render/3D (рисование) 13 % —
Video (декодирование) 1,1 % 6 %, пик 6,6 %
VideoEnhance (кодирование) 0 % 0 %

Частота GPU в эти секунды поднялась с ~50 до 126 МГц (пик 161), а доля простоя (RC6) оставалась 54 %.

Читается так: декодировало железо — движок Video занят, частота выросла; кодирование не использовалось; рисование окна шло своим чередом. Проценты небольшие, потому что ролик лёгкий: 1080p30 при 8 Мбит/с для этого чипа — простая задача. На 4K или HEVC цифры будут выше.

Если проверять декодирование через GStreamer

Иногда хочется проверить железо без браузера — например, прогнать файл через GStreamer. Тут есть ловушка, на которую легко наступить:

$ gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse ! vah264dec ! fakesink
ОШИБКА: конвейер не хочет подготавливаться (PREROLL)
streaming stopped, reason not-linked

vah264dec отдаёт кадры в памяти GPU (memory:VASurface), а обычный fakesink такие не принимает. Нужен конвертер из VA-поверхностей в обычную память — vapostproc из пакета gstreamer1.0-vaapi. Если этого пакета нет, пайплайн падает с not-linked, и его время работы (сотые доли секунды) не означает, что декодирование было быстрым — оно просто не состоялось.

Поэтому для проверки «в бою» надёжнее браузер: он умеет и VA-API, и вывод на экран.

И вторая ловушка — сам файл. Он должен быть в 4:2:0. x264enc, получив на вход RGB, охотно пишет High 4:4:4, а браузеры такой профиль не декодируют вообще: симптом ровно как при поломке — чёрный экран и таймер, стоящий на 0:00. Лечение — задать формат явно:

$ gst-launch-1.0 -q videotestsrc num-buffers=600 ! \
    video/x-raw,width=1920,height=1080,framerate=30/1,format=I420 ! \
    x264enc speed-preset=ultrafast bitrate=8000 ! h264parse ! mp4mux ! \
    filesink location=test1080p.mp4

Симптом → где искать

Симптом Где искать Что делать
Всё медленно, но ошибок нет; glxinfo показывает llvmpipe /dev/dri, права, параметры ядра Проверить доступ к renderD128; убрать nomodeset; поставить Mesa
Чёрный экран после обновления ядра Журнал загрузки, прошивки Загрузиться с прошлым ядром; проверить linux-firmware
Картинка «рвётся» при движении окна Настройки композитора (X11) Включить предотвращение разрывов; проверить, что композитор работает
Внешний монитор не определяется xrandr, kscreen-doctor, кабель Проверить кабель и режим; xrandr --output … --auto
Видео тормозит, вентилятор шумит vainfo, intel_gpu_top Поставить правильный драйвер VA-API, включить --hwdec
Артефакты, мусор на экране Журнал i915, версия Mesa Попробовать другое ядро или отключить энергосбережение GPU
Пропадает изображение на секунду Энергосбережение панели Параметры i915.enable_psr=0, i915.enable_fbc=0 — как диагностика

Параметры ядра: диагностика, а не лечение

Иногда советуют добавить nomodeset или i915.enable_psr=0. Важно понимать, что это:

  • nomodeset отключает управление режимами в ядре (KMS). Система загрузится в низком разрешении и без ускорения — это способ попасть в систему и починить, а не способ работать;
  • i915.enable_psr=0, i915.enable_fbc=0 отключают энергосберегающие функции панели. Полезно, чтобы проверить, из-за них ли мерцание, но держать это постоянно — значит мириться с повышенным расходом.

Добавить параметр на один раз: в меню загрузчика (GRUB) нажать e, дописать в строку linux и загрузиться. Постоянно — в файле /etc/default/grub, в GRUB_CMDLINE_LINUX_DEFAULT, затем обновить конфигурацию загрузчика:

# Debian/Ubuntu
$ sudo update-grub

# RPM-семейство (МОСТЕХ, РОСА, Fedora)
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Если нужна помощь: что приложить к вопросу

Чтобы не гадать, соберите один файл:

$ { lspci -k | grep -A3 -E 'VGA|3D'
    glxinfo -B 2>&1
    vainfo 2>&1 | head -30
    uname -r
    journalctl -k -b | grep -iE 'i915|drm|firmware' | tail -50
  } > gpu-report.txt

Этого достаточно, чтобы понять: работает ли GPU, какая версия Mesa и ядра, есть ли прошивки и что именно происходит в журнале.

Источники

  • Документация ядра: https://docs.kernel.org/gpu/ — DRM, i915, параметры.
  • Документация Mesa: https://docs.mesa3d.org/ — драйвер iris, OpenGL/Vulkan.
  • man 1 xrandr — мониторы и режимы; man 1 intel_gpu_top, man 1 vainfo — по пакетам intel-gpu-tools и libva-utils.
  • Документация KDE: https://docs.kde.org/ — «Экран и монитор», композитор.

Что ещё не проверено

  • Все команды приведены по документации. На рабочем ноутбуке (МОСТЕХ) они не выполнялись — доступа нет.
  • На этом ноутбуке (Ubuntu 26.04) проверено: i915, Wayland, панель 1920×1080, Mesa 26.0.8, рендерер UHD Graphics 620 (WHL GT2), OpenGL 4.6. VA-API: было returns -1, после установки драйвера — returns 0, 11 профилей декодирования и 4 точки кодирования (выше).
  • Не проверено здесь: vulkaninfo и intel_gpu_top (не установлены). glxinfo и vainfo проверены — их вывод приведён выше.
  • Работа декодера в браузере подтверждена: после полного перезапуска Яндекс Браузер показывает Decode h264/vp8/vp9/hevc.
  • Нагрузку на движок Video измерить не удалось: intel_gpu_top требует прав CAP_PERFMON (root), а проверка через GStreamer упирается в отсутствие vapostproc (см. выше). Рецепт для владельца: sudo intel_gpu_top в одном окне, воспроизведение 1080p-файла в браузере в другом — в строке Video должно быть заметно больше нуля, а Render при этом остаётся низким.
  • Источники: два экспорта chrome://gpu из Яндекс Браузера 26.8.0 — до перезапуска (26.10 00:07 MSK) и после (26.10 00:12 MSK). В файлах время в UTC (25.10 21:07Z и 21:12Z), это стоит помнить при сверке дат.
  • Имена пакетов и параметров могут отличаться между выпусками: проверять в своём менеджере пакетов и man-страницах.
Оценка статьи 0

Смотрите также

Комментарии

Пока комментариев нет.