Drm что это linux

Обновлено: 09.01.2025

Этот документ руководство по настройке аппаратного 3D-ускорения с помощью DRM и Xorg в Gentoo.

Введение

Что такое аппаратное 3D-ускорение и зачем оно нужно?

При наличии аппаратного 3D-ускорения для создания трёхмерных изображений используется графический процессор на видеокарте заместо использования ценных ресурсов процессора. Это также называется "аппаратным ускорением", а не "программным ускорением", поскольку без аппаратного 3D-ускорения ЦП вынужден отрисовывать всё самостоятельно, используя библиотеки Mesa, которые потребляют совсем немного вычислительной мощности.

While Xorg typically supports 2D hardware acceleration, it often lacks hardware 3D acceleration. Three-dimensional hardware acceleration is valuable in situations requiring rendering of 3D objects such as games, 3D CAD, and modeling.

Настройка аппаратного 3D-ускорения

Во многих случаях существуют как проприетарные драйвера, так и драйвера с открытым исходным кодом. Последние являются предпочтительными для Linux, поскольку открытость – это один из его основных принципов. Иногда проприетарные драйвера являются единственным выбором, особенно, если видеокарта настолько новая, что для неё ещё не написано драйверов с открытым исходным кодом. Проприетарные драйвера включают в себя x11-drivers/nvidia-drivers для видеокарт nVidia и x11-drivers/xf86-video-ati (ранее x11-drivers/ati-drivers) для старых видеокарт AMD/ATI и dev-libs/amdgpu-pro-opencl для новых AMD видеокарт.

Что такое DRI?

Direct Rendering Infrastructure, также известный как DRI, – это платформа, позволяющая получать прямой доступ к видеокарте безопасным и эффективным способом. Платформа включает в себя исправления для X сервера, некоторых клиентских библиотек и для ядра. Первое важнейшее применение DRI – создание быстрых дополнений OpenGL.

Что такое DRM и как он связан с Xorg?

DRM (Direct Rendering Manager) – это дополнение к Xorg, осуществляющее 3D-ускорение путём добавления модулей ядра, необходимых для прямого доступа к видеокарте.

Основная тема

Это руководство предназначено для тех, кто не может получить прямой доступ к видеокарте, работая только с Xorg. DRM работает со следующими драйверами:

3dfx (закрытый исходный код) (закрытый исходный код; устарело)
matrox (закрытый исходный код)
rage128
radeonhd (устарело)
mach64
sis300
via

Смотрите домашнюю страницу DRI для более подробной информации и документации.

Установка Xorg и настройка ядра

Установка Xorg

Пожалуйста, прочитайте Руководство по настройке Xorg, чтобы установить и запустить Xorg.

Настройка ядра

Узнайте, какая видеокарта, и включите только её.

Вывод может отличаться из-за разности в аппаратном обеспечении.

Если видеокарта не поддерживается ядром, можно достичь некоторого успеха установив параметр ядра agp=try_unsupported . Для поддержки AGP будут использоваться стандартные функции Intel. Для добавления этого параметра, отредактируйте файл конфигурации загрузчика.

Большинство ядер должно иметь эти опции. Это было настроено с использованием стандартного ядра sys-kernel/gentoo-sources.

Убедитесь, что /usr/src/linux является символической ссылкой на текущее ядро.

Компиляция и установка ядра

Не забудьте перенастроить grub.conf или lilo.conf .

Если используете LILO выполните команду:

Если используете GRUB 2 выполните команду:

Добавление пользователя(ей) в группу video

Далее, добавьте нужных пользователей в группу video.

Настройка direct rendering

Настройка Xorg

Надо надеяться, что добавления пользователя в группу video достаточно, чтобы задействовать direct rendering. Однако, может понадобиться дополнительных настроек в директории /etc/X11/xorg.conf.d/ . Имя нового конфигурационный файл, созданного в этой директории, может содержать английские буквы и цифры, и оканчиваться на .conf . Откройте любимый текстовый редактор и создайте файл с таким содержанием:

Замените radeon на необходимый драйвер.

Изменения, необходимые для автоматической загрузки модуля

Вы должны добавить модуль, используемый вашей видеокартой, в /etc/modules-load.d/video.conf , чтобы гарантировать, что он автоматически загружается при запуске системы.

Заметка
Если agpgart был скомпилирован как модуль, вам также придётся добавить его в /etc/modules-load.d/video.conf .

Тестирование 3D-ускорения

Перезагрузка в новое ядро

Перезагрузите компьютер выбрав новое ядром и войдите в систему под обычным пользователем. Настало время посмотреть насколько хорошо работает direct rendering. glxinfo и glxgears являются частями пакета x11-apps/mesa-progs, поэтому перед тем, как запускать их, убедитесь, что этот пакет установлен.

Нет необходимости загружать модули вашего драйвера или agpgart, даже если они были скомпилированы как модули. Они будут загружены автоматически.

Если будет выведено "No", значит 3D-ускорение не работает.

Проверьте частоту обновления (FPS) при обычном разрешении экрана. Это число должно быть значительно больше, чем до настройки DRM. Сделайте это пока ЦП настолько свободен, насколько это возможно.

Заметка
FPS может быть ограничен частотой обновления вашего дисплея, поэтому примите это во внимание, если glxgears выдаёт только 70-100 FPS. games-fps/xonotic или другие 3D-игры являются более лучшими средствами сравнения эффективности.

Получение максимальной отдачи от direct rendering

Если вы хотите настроить дополнительные функции, для повышения производительности или по другим причинам, смотрите таблицу характеристик на сайте DRI или список характеристик на Sourceforge.

Устранение проблем

Проблемы с рендерингом

Попробуйте выполнить modprobe radeon перед тем, как запускать X сервер (замените radeon на название вашего драйвера). Также попробуйте скомпилировать agpgart как часть ядра, а не как модуль.

Не удалось загрузить модуль ядра agpgart во время запуска startx

error: "[drm] failed to load kernel module agpgart" после запуска `startx` происходит из-за того что agpgart был скомпилирован как часть ядра, а не как модуль. Не обращайте на это внимание, пока у вас не появятся проблемы.

TV-Out на видеокартах Radeon

Драйвера разрабатываются проектом GATOS, объединённым с кодовой базой Xorg. Для вывода изображения на телевизор через TV-Out ничего особенного не требуется; x11-drivers/xf86-video-ati уже будет хорошо работать.

Поддержка новых видеокарт

Попробуйте использовать проприетарные драйвера. Для видеокарт AMD используйте ati-drivers . Если она всё равно не поддерживается, то используйте fbdev. Это медленно, но работает.

DRM, полное английское название Digital Rights Management, можно перевести как: Digital Rights Management.
Из-за характеристик цифровой информации должна существовать еще одна уникальная технология для усиления защиты авторских прав на эти цифровые аудио- и видеопрограммы, документы и электронные книги. Это технология управления цифровыми правами. Технология - DRM (управление цифровыми правами)

Холст (FrameBuffer), сцена рисования (CRTC), выходной преобразователь (Encoder), коннектор (Connector), а затем на дисплей

Один из типов - это защита мультимедиа, например зашифрованных фильмов, музыки, аудио и видео, а также потоковых мультимедийных файлов.
Другая категория - это зашифрованные документы, такие как Word, Excel, PDF и т. д.
DRM в основном использует технические средства для защиты документов, фильмов и музыки от пиратства.
Эта технология защищает цифровой контент путем шифрования цифрового контента и добавления правил использования. Правила использования могут определять, имеет ли пользователь право на воспроизведение.

Принцип работы технологии DRM состоит в том, чтобы сначала создать центр авторизации цифровых программ. Закодированное цифровое содержимое программы может быть зашифровано и защищено (заблокировано) с помощью ключа (Key), а в зашифрованном заголовке цифровой программы хранятся KeyID и URL-адрес центра авторизации программ. Когда пользователь находится по запросу, согласно информации KeyID и URL в заголовке программы, соответствующее дешифрование (разблокировка) ключа может быть отправлено после проверки и авторизации центром авторизации цифровых программ, и программа может быть воспроизведена.

Поскольку внутренний интерфейс и структура данных ядра Linux могут измениться в любое время, модуль DRI должен быть скомпилирован для конкретной версии ядра. Для версий ядра после 2.6.26 исходный код DRM (модуль ядра DRI) хранится в kernel / drivers / gpu / drm; в предыдущей версии исходный код находится в каталоге kernel / drivers / char / drm.
Каждый драйвер аппаратного ускорения 3D содержит модуль ядра, и все они должны использовать код поддержки DRM.
В Unix-подобном мире также существует DRM под названием The Direct Rendering Manager, который является компонентом инфраструктуры DRI (Direct Rendering Infrastructure). Роль DRI - обеспечить эффективное ускорение видео для Unix-подобных систем (очень важное применение - обеспечение ускорения для 3D-рендеринга).
DRI - Direct Rendering Infrastructure
DRI не является программным модулем. Напротив, DRI состоит из серии программных модулей. Целью внедрения DRI является ускорение трехмерной графики DRI - это программная архитектура, используемая для координации работы между ядром Linux, системой X windows, оборудованием трехмерной графики и движком рендеринга OpenGL.

1. DRM обеспечивает синхронный доступ к графическому оборудованию.

Система прямого рендеринга имеет несколько объектов (таких как X-сервер, несколько клиентов прямого рендеринга и ядро), конкурирующих за доступ к графическому оборудованию. Видеокарты ПК используют блокировки, когда несколько объектов обращаются к графическому оборудованию. DRM обеспечивает блокировку каждого графического устройства для синхронизации доступа к оборудованию. Например, X-сервер выполняет 2D-рендеринг, а клиент прямого рендеринга выполняет программный обратный вызов, который может читать и записывать буфер кадра. Для некоторых высокопроизводительных карт, поскольку оборудование само сортирует команды доступа, нет необходимости использовать эту блокировку.

2. Когда DRM обращается к графическому оборудованию, оно применяет стратегию тестирования безопасности DRI.

X-сервер работает с привилегиями root.При доступе к фреймбуферу и областям MMIO графической карты он использует / dev / mem для сопоставления этих областей. Клиент прямого рендеринга не работает с привилегиями root, но по-прежнему требует аналогичного сопоставления. Интерфейс устройства DRM позволяет клиенту создавать эти сопоставления, но должны соблюдаться следующие ограничения: * Эти области могут быть сопоставлены только тогда, когда клиент подключен к X-серверу, что заставляет клиента прямого рендеринга соответствовать обычной политике безопасности X-сервера. * Эти области могут быть отображены только тогда, когда клиент может открыть / dev / drm ?. Это позволяет системным администраторам настроить прямой доступ к рендерингу, чтобы только доверенные пользователи могли получить к нему доступ. * Клиент может отображать только область, разрешенную X-сервером.

3. DRM обеспечивает общий механизм DMA.

Графическое оборудование большинства современных ПК обеспечивает доступ DMA к команде FIFO. Доступ DMA имеет лучшую пропускную способность, чем доступ MMIO. Для этих видеокарт механизм DMA, предоставляемый DRM, включает следующие функции: *
Связь между DRM и DRI

Мы видим, что DRM является компонентом DRI, а DRI также включает kms и драйвер OPenGLES DRI.

Инфраструктура DRM предоставляет серию поведений IOCTL, но большинство из них можно разделить на два типа поведения: Диспетчер выполнения графики (GEM), Настройка режима ядра (KMS) Следующий скриншот WIKI, приведенный в предыдущем абзаце:

Since then, the scope of DRM has been expanded over the years to cover more functionality previously handled by user space programs, such as framebuffer managing and mode setting, memory sharing objects and memory synchronization.[4][5] Some of these expansions had carried their own specific names, such as Graphics Execution Manager (GEM) or Kernel Mode-Setting (KMS), and the terminology prevails when the functionality they provide is specifically alluded. But they are really parts of the whole kernel DRM subsystem.

Первый GEM в основном предназначен для управления FrameBuffer, такого как выпуск приложения памяти (управление Framebuffer), объектов совместного использования памяти (объектов общего доступа к памяти) и синхронизации памяти (синхронизация памяти), в то время как последний KMS в основном предназначен для завершения настройки графической карты (настройка режима отображения) ,
Теперь сопоставьте драйвер Rockchip drm с вышеупомянутым. Rockchip_drm_gem *, конечно, соответствует GEM.rockchip_drm_vop* / analogix_dp-rockchip* / dw_hdmi-rockchip* Это определенно относится к KMS, и на этот раз мы также играем с последним KMS (Kernel Mode Setting）.

2. Драйвер графического устройства

Давайте сначала процитируем абзац из WIKI, чтобы кратко описать состав устройства видеокарты:

Due to the fact that dies of modern GPUs found on graphics cards for desktop computers integrate “processing logic”, “display controller” and “hardware video acceleration” SIP cores, non-technical people don’t distinguish between these three very different components. SoCs on the other hand, regularly mix SIP from different developers, and, for example, ARM’s Mali SIP does not feature a display controller. For historical reasons, the DRM and the KMS of the Linux kernel were amalgamated into one component. They were split in 2013 for technical reasons.[16]

Графическая карта в основном состоит из трех типов устройств:Processing logic Относится к таинственному модулю графического процессора,Display controller Относится к контроллеру LCDC,Hardware video acceleration Относится к конкретному интерфейсу дисплея HDMI / eDP /…
В соответствии с приведенной выше концепцией устройства, давайте соответствовать конкретному драйверу:

К сожалению, логика обработки не находится в каталоге, который я разработал
Контроллер дисплея должен управляться VOProckchip_drm_vop*
Аппаратное ускорение видео - драйвер HDMI / eDPanalogix_dp-rockchip* & dw_hdmi-rockchip*

Концепция DRM KMS (настройка режима ядра), которая будет представлена в этот раз, относится к совокупности вышеупомянутых элементов, в частности, VOP (процессор вывода видео) / драйвер стороны HDMI / eDP. DRM KMS имеет три понятия CRTC / Encoder / Connector для драйверов графических устройств. Эти три понятия важны, но их легко понять. CRTC означаетDisplay ControllerЭнкодер относится к конкретному интерфейсу драйвераeDP / HDMIРазъем относится к конкретному внешнему экрануMonitor / Panel。

Общее поведение CRTC выглядит следующим образом:
- DPMS (Display Power Manage System) управление состоянием питания (crtc_funcs-> dpms)
- Конвертирование Framebuffer в стандартный LCDC Timing - это процесс обновления кадра изображения (crtc_funs-> mode_set)
- Переключение кадров, то есть во время стирания VBlank, переключение Framebuffer (crtc_funcs-> page_flip) Корректировка значения коррекции (crtc_funcs-> gamma_set)
Общее поведение Encoder следующее:
- DPMS (Display Power Manage System) управление состоянием питания (encoder_funcs-> dpms)
- Преобразование выхода синхронизации lcdc VOP в соответствующий интерфейс синхронизацииHDMI TMDS / … (encoder_funcs->mode_set)
Общее поведение Connector выглядит следующим образом:
- Получите отчет о состоянии горячей замены
- Прочитать и проанализировать информацию EDID панели

Я просто беру процесс, отображаемый монитором HDMI, в качестве примера, а поведение CRTC / Encoder / Connector анализируется на примере:
1. Сначала драйвер HDMI обнаруживает сигнал ТВ-плагина, считывает сигнал ТВ-EDID и получает информацию о разрешении телевизора (разъем DRM).
2. Пользовательское пространство заполняет буфер кадров данными для отображения, а затем уведомляет устройство VOP о начале отображения через интерфейс libdrm.
3. Затем драйвер VOP преобразует данные в буфере кадров в стандартную синхронизацию LCDC (DRM CRTC).
4. В то же время драйвер HDMI сопоставляет аппаратную конфигурацию синхронизации ЖК-дисплея аппаратного модуля HDMI с синхронизацией выхода VOP и подготавливает преобразовать синхронизацию входного LCDC в сигнал HDMI TMDS (кодер DRM), распознаваемый телевизором.

Конкретные детали API драйвера CRTC / Encoder / Connector не будут отражены на этот раз, это просто концептуальное введение. В будущем у меня будет возможность разбить его по одному. Наконец, это No Picture Say JB. Блок-схема структуры DRM, общее и детали очень хорошо поняты.

TL;DR — Если ваше графическое окружение Linux во время просмотра видео, сеанса игры или прокрутки интерактивной веб страницы не успевает вовремя обновлять картинку целиком, то тогда для вас имеет смысл установить последнюю стабильную версию ядра ≥ 4.10.

Давным давно, то есть несколько лет назад каждая реализация протокола X11 предполагала смену режима видео напрямую, поперек батьки кернела. Затем появился KMS (kernel mode setting) и эта важная функция перешла к ядру. Но остались некоторые шероховатости. Атомарная смена режима является дальнейшим улучшением механизма KMS.

Для чего нужны атомарные операции KMS? Главным образом для того, чтобы избежать вот таких моментов.

Атомарная смена режима видео

DRM драйвер с поддержкой атомарной смены режима, a․ k․ a․ atomic mode setting имеет полезное свойство, которое заключается в том, что изменения видео режима проходят полную проверку прежде, чем вступят в силу. Это делается с целью обеспечить их корректное исполнение в драйверах и на дисплее с тем, чтобы избавить пользователей от мерцания, тиринга и прочих артефактов изображения. Скорость исполнения при этом также повышается. Звучит неплохо, а как это работает?

Framebuffer — Видео память, однако в терминологии KMS это скорее пул источников памяти видео — объектов GEM, для которого заданы такие характеристики как активная зона памяти, или то, что будет изображено, а также формат данных, длина шага.

CRTC — Аббревиатура расшифровывается как Cathode Ray Tube Controller, CRT Controller. Мало кто в нынешнее время использует мониторы на электронно-лучевых трубках, однако историческое название сохранилось с виде абстракции железа, которое считывает байты с памяти видео-карты и выдает пиксели на шину данных.
Encoder — Интерфейс между разнородными источниками видео, читает с CRTC и передает в соединительный разъем, a․ k․ a․ Connector . Один CRTC может иметь несколько кодеров.
Connector — Это может быть представлением для соединительного разъема монитора или же самим монитором в случае встроенных устройств с подключенных внешним экраном.
Planes — Слой или план изображения на CRTC .

Для этого надо понять как изменяется видео режим без этого нововведения. Рассмотрим обычный сценарий, в котором пользователь смотрит видео в окне браузера или плеера, не в полный экран, используя аппаратное ускорение. Видео образует передний план, окно и декорации браузера или плеера, это второй — задний план.

Драйверу видео передается список различных параметров: кадровый буфер, CRTC, экраны, режим.
Пользователь перемещает окно плеера.
Для этого нужно подгрузить новую страницу, a․ k․ a․ page flip, например.
Если новая страница не синхронизирована между передним и задним планом, видео сместится относительно своего окна.

Механизма, обеспечивающего синхронизацию на предпоследнем шаге нет, отсутствовал ioctl() , который выполнял бы всю работу. Например, только основной план имел механизм неблокирующих обновлений критичных с точным завершением событий. А для того, чтобы обновления произошли в нескольких слоях, требовалось куча системных вызовов из пользовательского пространства в надежде на то, что они завершатся синхронно. В то же время атомарные операции KMS имеют встроенную защиту от этого. Вместо трех разных ioctl() , все изменения проходят в одном единственном ioctl() .

Вообще-то проблему отсутствия синхронизации между активной зоной и задним планом во время просмотра видео решалась компоновкой всего с помощью GL, так как последний умеет обновлять кадры синхронно с VBlank. Все бы хорошо, только вот для мобильных устройств это не приемлемо из за высоких требования к памяти и питанию со стороны GL компоновщика.

Работы над «атомным» проектом началась в 2015-м с патчей Дейва Эйрли (Dave Airlie), затрагивающих интеловские i915 и еще несколько драйверов, плюс новое атомарное API.

В настоящий момент атомарный процесс обновлений происходит следующим образом.

Все изменения передаются ядру одним списком свойств (в середине картинки Properties ).
Ядро генерирует состояние устройства (справа на картинке State ).
atomic_check() проверяет валидность всех элементов списка свойств. Если есть ошибка ioctl() вернет уведомление об ошибка и отменит обновления.
atomic_commit() также в соответствии с названием вводит изменения в действие, если на предыдущем шаге atomic_check() завершился без ошибок.

Структура атомарной KMS определена в файле /usr/include/uapi/drm/drm_mode.h .

Для открытых драйверов Nouveau от Nvidea атомарный KMS включен по умолчанию начиная с версии Linux 4.10, для драйверов Intel — начиная с 4.12. Дальше — больше!

Читайте также: