Войти
| Автор (ы) оригинала | kernel.org freedesktop.org |
|---|---|
| Разработчик (и) | kernel.org freedesktop.org |
| Написано на | C |
| Тип | |
| Лицензия | |
| Веб-сайт | dri.freedesktop.org / wiki / DRM |
The Direct Rendering Manager (DRM ) - это подсистема ядра Linux, отвечающая за взаимодействие с графическими процессорами современными видеокарт. DRM предоставляет API, который программы пользовательского пространства могут использовать для отправки команд и данных в графический процессор и таких операций, как настройка режима режима дисплея. DRM сначала разработан как компонент ядра ядра в X Server Инфраструктура прямого рендеринга, но с тех пор он использовался другими альтернативами графического стека, такими как Wayland.
Программы пользовательского пространства могут использовать DRM API, чтобы дать команду графического процессору выполнить аппаратно-ускоренное 3D-рендеринг и декодирование видео, а также GPGPU вычислений.
Linux ядро уже имело API под названием fbdev, используемое для управления кадровым буфером графического адаптера , но его нельзя было использовать для потребностей современного видеооборудования на базе GPU с 3D-ускорением. Эти устройства обычно требуют установки и управления очередью команд в их собственной памяти для отправки команд на GPU, а также требуют управления буферами и свободным пространством в этой памяти. Первоначально используемые программы пользовательского пространства (такие как X Server ) напрямую управляли этими ресурсами. Когда две или более программы пытались управлять одним и тем же оборудованием одновременно и устанавливали свои ресурсы по своему, в большинстве случаев они заканчивались катастрофически.
Без DRM 
С DRM DRM допускает использование нескольких программ одновременного доступа к 3D-видеокарте, избегая Менеджер прямого рендеринга был создан, чтобы нескольким программам совместно использовать ресурсы видеооборудования. DRM получает эксклюзивный доступ к графическому процессу и отвечает за инициализацию и поддержку очереди команд, памяти и другого аппаратного ресурса. Программы, желающие использовать GPU, отправляют запросы в DRM.
Объем DRM с годами расширился, чтобы охватить больше функций, которые ранее обрабатывались программой пользовательского пространства, таких как управление кадровым буфером и установка режима, объекты совместного использования памяти и синхронизация памяти. Некоторым из этих расширений были даны полномочия, такие как Graphics Execution Manager (GEM) или настройка режима ядра (KMS).. Но на самом деле они являются частями всей подсистемы DRM ядра.
Тенденция включения двух графических процессоров в компьютер - дискретного графического процессора и интегрированного - привела к новым задачам, таким как переключение графических процессоров, которые также необходимо было решить на уровне DRM. Чтобы соответствовали технологии Nvidia Optimus, DRM была предоставлена возможность разгрузки графического процессора, называемая PRIME.
Процесс, использующий диспетчер прямого рендеринга ядра Linux для доступа к графической карте с 3D-ускорением Менеджер прямого рендеринга находится в пространстве ядра, поэтому программы пользовательского пространства должны использовать вызовы ядра для запроса своих услуг. Однако DRM не определяет свои собственные настраиваемые системные вызовы. Вместо этого он следует принципу Unix «все является файлом », чтобы раскрыть графические процессоры через пространство имен файловой системы, используя файлы устройств в иерархии / dev. Каждый графический, обнаруженный DRM, называется DRM, и для взаимодействия с ним создается файл устройства / dev / dri / cardX(где X - порядковый номер). Программы пользовательского пространства, которые хотят взаимодействовать с GPU, должны открыть этот файл и использовать вызовы ioctl для связи с DRM. Разные ioctl соответствуют различным функциям DRM API.
A . Библиотека, называемая libdrm, была создана для облегчения взаимодействия программ пользовательского пространства с подсистемой DRM. Эта библиотека представляет собой просто оболочку, которая предоставляет функцию , написанную на C для каждого ioctl DRM API, а также константы, структуры и другие элементы. Использование libdrm не только позволяет избежать прямого доступа к интерфейсу приложения ядра, но и использует обычные преимущества повторного использования и совместное использование кода между программами.
Детали архитектуры Direct Rendering Manager: ядро DRM и драйвер DRM (включая GEM и KMS) с интерфейсом libdrm DRM состоит из двух частей: общего «ядра DRM» и отдельной («драйвер DRM») для каждого типа поддерживаемого оборудования. Ядро DRM обеспечивает базовую структуру, которая может регистрироваться различными средствами DRM, а также предоставляет пользовательскому пространству минимальный набор ioctl с общими аппаратно-независимыми функциями. Драйвер DRM, с другой стороны, реализует аппаратно-зависимую часть API, зависящую от типа поддерживаемого графического процессора; он должен обеспечивать работу остальных ioctl, не охваченных ядром DRM, но он также может расширять API, предлагая дополнительные функции ioctl с дополнительными функциями, доступными только на таком оборудовании. Когда конкретный драйвер DRM предоставляет расширенный API, libdrm пользовательского пространства также расширяет дополнительную библиотекой libdrm-driver, который может быть пользовательским пространством для взаимодействия с дополнительными ioctls.
Ядро DRM экспортирует несколько интерфейсов в приложения пользовательского пространства, обычно предназначенные для использования через соответствующие функции-оболочки libdrm. Кроме того, драйверы экспортируют интерфейсы пользовательских устройств для использования драйверами пространства и приложениями, поддерживающими устройства, через файлы ioctls и sysfs. Внешние интерфейсы включают: отображение памяти, управление контекстом, операции DMA, управление AGP, управление vblank, управление ограничением, управление памятью и управление выводом.
В DRM API есть несколько операций (ioctls), которые либо в целях безопасности, либо для проблем параллелизма должны быть ограничены для использования одного - космического процесса на устройство. Чтобы реализовать это ограничение, DRM ограничивает такие ioctl вызовом только процесса, который считается «ведущим» устройством DRM, обычно называемым DRM-Master. Только один из всех процессов, у которых открыт узел устройства / dev / dri / cardX, будет иметь свой дескриптор файла , помеченный как главный, а именно первый, вызывающий SET_MASTER ioctl. Любая попытка использовать один из этих ограниченных ioctl без DRM-Master вернет ошибку. Процесс также может отказаться от своей роли мастера и другим способом получить ее, вызвав DROP_MASTER ioctl.
X-сервер - или любой другой сервер отображения - представляет процесс, который получает статус DRM-Master в каждом устройстве DRM, которым он управляет, обычно при открытии соответствующего узла устройства во время его запуска, в режиме онлайн-доступа для всего графического сеанса, пока он не завершится или не умрет.
Для предоставленных процессов пользовательского пространства есть другой способ получить доступ к некоторым ограниченным операциям на устройстве DRM, называемый DRM-Auth. По сути, это метод аутентификации устройства DRM, чтобы доказать ему, что процесс имеет одобрение DRM-Master для получения таких привилегий. Процедура состоит из:
Из-за увеличения размера видеопамяти и растущей сложности графических API, таких как OpenGL, стратегия повторной инициализации состояния видеокарты при каждом переключении контекста было слишком дорого с точки производительности. Кроме того, современные настольные компьютеры Linux нуждались в оптимальном способе совместного использования буферов вне системы менеджером композитинга. Эти требования приводят к разработке новых методов управления графическими буферами внутри ядра. Graphics Execution Manager (GEM) появился как один из этих методов.
GEM предоставляет API с явными примитивами управления памятью. С помощью GEM программа пользовательского пространства может создавать, обрабатывать и уничтожать объекты памяти, живущие в видеопамяти графического процессора. Эти объекты, называемые «объектами GEM», являются постоянными с точки зрения программы пользовательского пространства не нуждаются в перезагрузке каждый раз, когда программа восстанавливает контроль над графическим процессором. Когда программе пользовательского пространства требуется фрагмент видеопамяти (для хранения фреймбуфера, текстуры или любых других данных, требуемых графическим процессором), она запрашивает выделение в DRM-драйвере, используя GEM API. Драйвер DRM отслеживает используемую видеопамять и может выполнить запрос, если имеется свободная память, возвращая «дескриптор» пользовательского пространства для дальнейшего к выделенной памяти в предстоящих операциях. GEM API также действует по заполнению буфера и освобождению его, когда он больше не нужен. Память из невыпущенных дескрипторов GEM восстанавливается, когда процесс пользовательского пространства закрывает устройство DRM файловый дескриптор - намеренно или из-за его завершения.
GEM также допускает два или более пользовательских пространства обрабатывает, используя одно и то же устройство DRM (следовательно, тот же драйвер DRM) для совместного использования объекта GEM. Дескрипторы GEM - это локальные 32-битные целые числа, уникальные для процесса, но повторяющиеся в других процессах, поэтому не подходят для совместного использования. Что необходимо, так это глобальное пространство имен, и GEM предоставляет его с помощью глобальных дескрипторов, называемых именами GEM. Имя GEM относится к одному и только одному объекту GEM, созданному в одном устройстве DRM одним и тем же драйвером DRM с использованием уникального 32-битного целого числа. GEM выполнить операцию для получения имени GEM из дескриптора GEM. Затем процесс может передать это имя GEM (32-битное целое число) другим способом, используя любой доступный механизм IPC. Имя GEM может локального получения сообщения локального дескриптора GEM, указывающего на исходный объект GEM.
К сожалению, использование имен GEM для совместного использования буферов небезно. Вредоносный сторонний процесс, обращающийся к тому же устройству DRM, может попытаться угадать имя GEM буфера, используемого другими другими процессами, просто путем проверки 32-битных целых чисел. После, как имя GEM найдено, его содержимое может быть доступно и изменено, нарушая конфиденциальность и целостность информации буфера. Этот недостаток был преодолен путем введения поддержки DMA-BUF в DRM.
Еще одна важная задача для любой системы управления видеопамятью, внешним управлением пространством видеопамяти, - это обработка синхронизации памяти между GPU и CPU. Современная память очень сложны и обычно включают уровни кешей для системной памяти, а иногда и для видеопамяти. Следовательно, менеджеры видеопамяти должны также обрабатывать согласованность кэша, чтобы согласованность данных, совместно используемых между ЦП и ГП. Это означает, что внутренние механизмы управления видеопамятью зависят от аппаратных характеристик графического процессора и архитектуры памяти и, следовательно, зависят от драйвера.
GEM изначально был разработан инженерами Intel для обеспечения менеджер видеопамяти для своего драйвера i915. Семейство Intel GMA 9xx - это интегрированные графические процессоры с унифицированной архитектурной памятью (UMA), где графический процессор и процессор используют физическую память, а выделенная видеопамять отсутствует. GEM определяет «домены памяти» для синхронизации памяти, и хотя эти домены памяти не зависят от графического процессора, они специально разработаны с учетом архитектуры памяти UMA, что делает их менее подходящими для других архитектурных памяти, например, с отдельной VRAM. По этой другой драйверы DRM предоставили программам пользовательского пространства GEM API, но внутри они реализовали другой диспетчер памяти, более подходящий для их конкретного оборудования и архитектуры.
GEM API также предоставляет ioctls для управления потоком выполнения (буферы команд), но они специфичны для Intel и должны работать с Intel i915 и более поздними графическими процессорами. Ни один другой драйвер DRM не сможет реализовать какую-либо часть GEM API, кроме специфичных для управления памятью ioctl.
Карты трансляции (TTM) - это название универсального менеджера памяти для графических процессоров, который был разработан до GEM. Он специально разработан для управления различными типами памяти, к которой может обращаться графический процессор, включая выделенную видеопамять (обычно устанавливается на видеокарте) и системную память, доступную через Блок управления памятью ввода / вывода вызвал таблицу переназначения адресов графики (GART). TTM также должен обрабатывать части видеопамяти, которые напрямую не адресуются ЦП, и делать это с максимально возможной производственной системой, как правило, с большими объемами видеоданных. Другим важным было обеспечение согласования между различными воспоминаниями и задействованными тайниками.
Основная концепция TTM - это «буферные объекты», области видеопамяти, которые в какой-то момент должны быть адресованы графическому процессу. Когда графическому приложению пользовательского пространства требуется доступ к определенному объекту буфера (обычно для заполнения его содержимым), TTM может заменить его в тип памяти, адресуемой ЦП. Дальнейшие перемещения или операции сопоставления GART - может произойти, когда объект графического процессору требуется к объекту буфера, но он еще не находится в адресном пространстве графического процессора. Каждую из этих операций перемещать должны обрабатывать любые связанные данные и проблемы с согласованием кеша.
Еще одна важная концепция TTM - ограждения. По сути, ограждения - это механизм управления параллелизмом между ЦП и ГП. Забор отслеживает, когда буферный объект больше не используется графическим процессом, обычно для любого процесса пользовательского пространства, имеющего к нему доступ.
Тот факт, что TTM пытался управлять всеми типами архитектур памяти, включая те, которые и без выделенной видеопамяти, подходящим способом и для использования всех мыслимых функций в диспетчере памяти для использования с любым типом оборудования, приводит к чрезмерно сложному решение с API, намного большим, чем необходимо. Некоторые разработчики DRM думают, что это не подходит для какого-либо конкретного драйвера, особенно для API. Когда GEM превратился в более простой менеджер памяти, его API был предпочтительнее, чем API TTM. Но некоторые разработчики драйверов посчитали, что подход, принятый TTM, больше подходит для дискретных видеокарт с выделенной видеопамятью и IOMMU, поэтому они решили использовать TTM внутренне, выставляя свои буферные объекты как объекты GEM и, таким образом, поддерживая GEM API. Примеры текущих драйверов, использующих TTM в качестве диспетчера внутренней памяти, но предоставляющих GEM API, - это драйвер Radeon для видеокарт AMD и драйвер nouveau для видеокарт NVIDIA.
DMA Buffer Sharing API (часто сокращенно DMA-BUF) - это ядро Linux внутренний API, предназначенный для предоставляют общий механизм для совместного использования буферов DMA между несколькими устройствами, возможно, управляемыми разными типами драйверов устройств. Например, устройство Video4Linux и устройство графического адаптера могут совместно использовать буферы через DMA-BUF для достижения нулевого копирования данных видеопотока, созданного первым и потребляемого последнее. Любой драйвер устройства Linux может реализовать этот API как экспортер, как пользователь (потребитель) или и то, и другое.
Эта функция была впервые использована в DRM для реализации PRIME, решения, использующего DMA-BUF для совместного использования результирующих буферов кадра между драйверами DRM дискретного и интегрированного GPU. Важной особенностью DMA-BUF является то, что совместно используемый буфер представлен пользовательскому пространству как файловый дескриптор . Для разработки PRIME в DRM API были добавлены два новых файла ioctl, один для преобразования локального дескриптора GEM в файловый дескриптор DMA-BUF, а другой для прямо противоположной операции.
Эти два новых файла ioctl были позже повторно использованы как способ исправить внутреннюю небезопасность совместного использования буфера GEM. В отличие от имен GEM, файловые дескрипторы невозможно угадать (они не являются глобальным пространством имен), а операционные системы Unix предоставляют безопасный способ их передачи через сокет домена Unix с использованием семантики SCM_RIGHTS. Процесс, который хочет поделиться объектом GEM с другим процессом, может преобразовать свой локальный дескриптор GEM в файловый дескриптор DMA-BUF и передать его получателю, который, в свою очередь, может получить свой собственный дескриптор GEM из полученного файлового дескриптора. Этот метод используется DRI3 для совместного использования буферов между клиентом и X-сервером, а также Wayland.
В пользовательском пространстве должен быть «мастер DRM», эта программа имеет эксклюзивный доступ к KMS. Для правильной работы видеокарта или графический адаптер должны установить режим - комбинацию разрешения экрана,, глубина цвета и частота обновления - то есть в пределах диапазона значений, поддерживаемых им самим и прикрепленным экраном дисплея. Эта операция называется установкой режима и обычно требует прямого доступа к графическому оборудованию, т.е. возможность записи в определенные регистры видеокарты. Операция установки режима должна выполняться перед началом использования буфера кадра , а также когда режим требуется изменить приложением или пользователем.
В первые дни программы пользовательского пространства, которые хотели использовать графический буфер кадра, также отвечали за обеспечение операций установки режима, и поэтому им требовалось работать с привилегированным доступом к видеооборудованию. В операционных системах типа Unix наиболее ярким примером был X Server, а его реализация настройки режима находилась в драйвере DDX для каждого конкретного типа видеокарты. Этот подход, позже именуемый установкой режима пользовательского пространства или UMS, создает несколько проблем. Это не только нарушает изоляцию, которую операционные системы должны обеспечивать между программами и оборудованием, вызывая как проблемы стабильности, так и безопасности, но также может оставить графическое оборудование в несогласованном состоянии, если две или более программы пользовательского пространства попытаются выполнить настройку режима в то же время. Чтобы избежать этих конфликтов, X-сервер стал практически единственной программой пользовательского пространства, которая выполняла операции установки режима; остальные программы пользовательского пространства полагались на X-сервер для установки соответствующего режима и обработки любых других операций, связанных с установкой режима. Первоначально установка режима выполнялась исключительно во время процесса запуска X-сервера, но позже X-сервер получил возможность делать это во время работы. Расширение XFree86-VidModeExtension было введено в XFree86 3.1.2, чтобы позволить любому запросу X-клиента modeline (разрешение) изменяться на X-сервере. Расширение VidMode было позже заменено более общим расширением XRandR.
Однако это был не единственный код, выполняющий настройку режима в системе Linux. В процессе загрузки системы ядро Linux должно установить минимальный текстовый режим для виртуальной консоли (на основе стандартных режимов, определенных расширениями VESA BIOS ). Кроме того, драйвер фреймбуфера ядра Linux содержал код установки режима для настройки устройств фреймбуфера. Чтобы избежать конфликтов настроек режима, сервер XFree86 - а позже сервер X.Org - обрабатывал случай, когда пользователь переключался с графической среды на текстовую виртуальную консоль . путем сохранения состояния настройки режима и восстановления его, когда пользователь переключился обратно на X. Этот процесс вызвал раздражающее мерцание при переходе, а также может завершиться ошибкой, что приведет к повреждению или непригодности вывода на дисплей.
Подход к настройке режима пользовательского пространства также вызвал другие проблемы:
Для решения этих проблем код установки режима был перемещен в одно место внутри ядра, в частности, в существующий Модуль DRM. Затем каждый процесс, включая X-сервер, должен иметь возможность отдавать команду ядру на выполнение операций по настройке режима, и ядро должно гарантировать, что параллельные операции не приведут к несогласованному состоянию. Новый API ядра и код, добавленные в модуль DRM для выполнения этих операций по настройке режима, были названы настройкой режима ядра (KMS).
Настройка режима ядра дает несколько преимуществ. Самым незамедлительным, конечно же, является удаление повторяющегося кода установки режима как из ядра (консоль Linux, fbdev), так и из пользовательского пространства (драйверы X Server DDX). KMS также упрощает написание альтернативных графических систем, которым теперь не нужно реализовывать собственный код установки режима. Предоставляя централизованное управление режимами, KMS решает проблемы мерцания при переключении между консолью и X, а также между различными экземплярами X (быстрое переключение пользователей). Поскольку он доступен в ядре, его также можно использовать в начале процесса загрузки, что позволяет избежать мерцания из-за изменений режима на этих ранних этапах.
Тот факт, что KMS является частью ядра, позволяет ему использовать ресурсы, доступные только в пространстве ядра, такие как прерывания. Например, восстановление режима после приостановки / возобновления процесса значительно упрощается за счет управления самим ядром и, в частности, повышает безопасность (больше нет инструментов пользовательского пространства, требующих полномочий root). Ядро также позволяет легко подключать новые устройства отображения, решая давнюю проблему. Настройка режима также тесно связана с управлением памятью, поскольку фреймбуферы в основном являются буферами памяти, поэтому настоятельно рекомендуется тесная интеграция с менеджером графической памяти. Это основная причина, по которой код настройки режима ядра был включен в DRM, а не в качестве отдельной подсистемы.
Чтобы избежать нарушения обратной совместимости DRM API, настройка режима ядра предоставляется как дополнительная функция драйвера для определенные драйверы DRM. Любой драйвер DRM может выбрать предоставление флага DRIVER_MODESET при регистрации в ядре DRM, чтобы указать, что он поддерживает KMS API. Драйверы, реализующие настройку режима ядра, часто называют драйверами KMS, чтобы отличить их от устаревших - без KMS - драйверов DRM.
KMS была принята до такой степени, что некоторые драйверы, в которых отсутствует 3D-ускорение (или для которых поставщик оборудования не хочет предоставлять или реализовывать его), тем не менее, реализуют KMS API без остальной части DRM API..
KMS моделирует и управляет устройствами вывода как серией абстрактных аппаратных блоков, обычно встречающихся в конвейере вывода дисплея контроллера дисплея. Это следующие блоки:
В последние годы предпринимались постоянные усилия по обеспечению атомарности некоторых регулярных операций, связанных с KMS API, в частности, для операций настройки режима и переворачивания страниц. Этот усовершенствованный KMS API называется атомарным отображением (ранее называвшимся атомарной настройкой режима и атомарным или ядерным переворотом страницы).
Цель настройки атомарного режима - обеспечить правильное изменение режима в сложных конфигурациях с множеством ограничений, избегая промежуточных шагов, которые могут привести к несогласованному или недопустимому состоянию видео; это также позволяет избежать рискованных состояний видео, когда необходимо отменить неудачный процесс установки режима («откат»). Атомарная настройка режима позволяет заранее узнать, подходит ли определенная конкретная конфигурация режима, предоставляя возможности тестирования режима. Когда атомарный режим протестирован и его валидность подтверждена, его можно применить с помощью одной неделимой (атомарной) операции commit. Операции тестирования и фиксации предоставляются одним и тем же новым ioctl с разными флагами.
Атомарный переворот страницы, с другой стороны, позволяет обновлять несколько плоскостей на одном и том же выходе (например, первичную плоскость, плоскость курсора и, возможно, некоторые наложения или вторичные плоскости), все синхронизированные в одном VBLANK интервал, обеспечивая надлежащее отображение без разрывов. Это требование особенно актуально для мобильных и встроенных контроллеров дисплея, которые обычно используют несколько плоскостей / наложений для экономии энергии.
Новый атомарный API построен на старом KMS API. Он использует ту же модель и объекты (CRTC, кодировщики, соединители, плоскости и т. Д.), Но с увеличивающимся числом свойств объекта, которые можно изменять. Атомарная процедура основана на изменении соответствующих свойств для создания состояния, которое мы хотим протестировать или зафиксировать. Свойства, которые мы хотим изменить, зависят от того, хотим ли мы выполнить настройку режима (в основном CRTC, свойства кодировщиков и соединителей) или переворачивание страницы (обычно свойства плоскостей). Ioctl одинаков для обоих случаев, разница заключается в списке свойств, передаваемых с каждым из них.
В исходном API DRM устройство DRM / dev / dri / cardXиспользуется как для привилегированных (установка режима, другое управление отображением), так и для непривилегированных (рендеринг, GPGPU вычисления) операций. По соображениям безопасности открытие связанного файла устройства DRM требует особых привилегий, «эквивалентных привилегиям root». Это приводит к архитектуре, в которой только некоторые надежные программы пользовательского пространства (X-сервер, графический редактор и т. Д.) Имеют полный доступ к DRM API, включая привилегированные части, такие как API набора режимов. Остальные приложения пользовательского пространства, которые хотят отображать или производить вычисления GPGPU, должны быть предоставлены владельцем устройства DRM («DRM Master») посредством использования специального интерфейса аутентификации. Затем аутентифицированные приложения могут отображать или производить вычисления с использованием ограниченной версии API DRM без привилегированных операций. Этот дизайн налагает серьезное ограничение: всегда должен быть работающий графический сервер (X-сервер, композитор Wayland,...), действующий как DRM-Master устройства DRM, чтобы другим программам пользовательского пространства можно было разрешить использование устройства, даже в тех случаях, когда графический дисплей не используется, например, вычисления GPGPU.
Концепция «узлов рендеринга» пытается решить эти сценарии путем разделения API пользовательского пространства DRM на два интерфейса - один привилегированный и один непривилегированный - и использование отдельных файлов устройств (или «узлов») для каждого из них. For every GPU found, its corresponding DRM driver—if it supports the render nodes feature—creates a device file /dev/dri/renderDX, called the render node, in addition to the primary node /dev/dri/cardX. Clients that use a direct rendering model and applications that want to take advantage of the computing facilities of a GPU, can do it without requiring additional привилегии путем простого открытия любого существующего узла рендеринга и диспетчеризации операций графического процессора с использованием ограниченного подмножества API DRM, поддерживаемого этими узлами, при условии, что у них есть разрешения файловой системы для открытия файла устройства. Серверы отображения, композиторы и любая другая программа, для которой требуется API набора мод или любая другая привилегированная операция, должны открыть стандартный основной узел, который предоставляет доступ к полному API DRM, и использовать его как обычно. Узлы рендеринга явно запрещают операцию мигания GEM, чтобы предотвратить совместное использование буфера с использованием небезопасных глобальных имен GEM; только PRIME (DMA-BUF) файловые дескрипторы могут использоваться для совместного использования буферов с другим клиентом, включая графический сервер.
DRM должна использоваться в пользовательском режиме драйвер графических устройств, например, AMD Catalyst или Mesa 3D. Программы пользовательского пространства используют интерфейс системных вызовов Linux для доступа к DRM. DRM дополняет интерфейс системных вызовов Linux собственными системными вызовами. Подсистема Linux DRM включает бесплатные драйверы с открытым исходным кодом для поддержки оборудования от трех основных производителей графических процессоров для настольных компьютеров (AMD, NVIDIA и Intel), а также от растущего числа интеграторов мобильных GPU и System on a chip (SoC). Качество каждого драйвера сильно различается в зависимости от степени сотрудничества производителя и других вопросов.
| Драйвер | Начиная с ядра | Поддерживаемое оборудование | Поддержка поставщика | Статус / Примечания |
|---|---|---|---|---|
| radeon | 2.4.1 | AMD (ранее ATi) Radeon серии GPU с архитектурами TeraScale и GCN 1st 2nd gen. Включая модели из R100 / 200 / 300 / 400, Radeon X1000, HD 2000 / 4000 / 5000 / 6000 / 7000 / 8000, R5 / R7 / R9 200 / 300 серии и Kaveri APU. | Да | Активный |
| i915 | 2.6.9 | Intel GMA 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G, Чипсеты G35, G41, G43, G45. Intel HD и Iris Graphics Встроенные графические процессоры HD Graphics 2000/3000/2500/4000/4200/4400/4600 / P4600 / P4700 / 5000, Iris Graphics 5100, Iris Pro Graphics 5200. | Да | Активный |
| nouveau | 2.6.33 | NVIDIA Tesla, Fermi, Kepler, Maxwell на базе GeForce GPU, Tegra K1, X1 SoC | Partial | Active |
| exynos | 3.2 | Samsung SoC Exynos на базе ARM | ||
| vmwgfx | 3.2 (из стадии подготовки) | Виртуальный графический процессор для VMware SVGA2 | виртуальный драйвер | |
| gma500 | 3.3 (из стадии подготовки) | Intel GMA 500 и другие Imagination Technologies (Графические процессоры на основе PowerVR ) | экспериментальный 2D-драйвер только для KMS | |
| ast | 3.5 | ASpeed Technologies 2000 series | экспериментальный | |
| mgag200 | 3.5 | Серверы отображения Matrox MGA-G200 | KMS-only | |
| shmobile | 3.7 | Renesas SH Mobile | ||
| tegra | 3.8 | Nvidia Tegra 20, Tegra30 SoC | Да | Активный |
| omapdrm | 3.9 | Техас Инструменты OMAP 5 SoC | ||
| rcar-du | 3.11 | Ren esas R-Car SoC Display Units | ||
| msm | 3.12 | Qualcomm Adreno семейства A2xx / A3xx / A4xx GPU (Snapdragon SOC) | ||
| armada | 3.13 | Marvell Armada 510 SoC | ||
| bochs | 3.14 | Virtual VGA карты с использованием интерфейса vga Bochs dispi (например, QEMU stdvga) | виртуальный драйвер | |
| sti | 3.17 | STMicroelectronics SoC stiH41x серия | ||
| imx | 3,19 (от staging) | Freescale i.MX SoC | ||
| rockchip | 3,19 | Rockchip Графические процессоры на базе SoC | Только KMS | |
| amdgpu | 4.2 | AMD Серия графических процессоров Radeon с архитектурами GCN 3rd 4-й генерал. Включая модели серий Radeon Rx 200 / 300 / 400 / 500 и Carrizo и Bristol Стоуни Ридж ВСУ. | Да | Активный |
| virtio | 4.2 | драйвер виртуального графического процессора для управления виртуальных машин на основе QEMU (например, KVM или Xen ) | виртуальный драйвер | |
| vc4 | 4.4 | Raspberry Pi Broadcom BCM2835 и BCM2836 SoC (VideoCore IV GPU) | ||
| etnaviv | 4.5 | Vivante GPU-ядра, присутствующие в нескольких SoC, таких как Marvell ARMADA и Freescale i.MX6 Серия | ||
| sun4i | 4.7 | Allwinner SoC (ARM Mali-400 GPU) | ||
| kirin | 4.7 | HiSilicon Kirin hi6220 SoC (ARM Mali 450-MP4 GPU) | ||
| mediatek | 4.7 | MediaTek MT8173 SoC (Imagination PowerVR GX6250 GPU) | ||
| hibmc | 4.10 | HiSilicon hi1710 Huawei iBMC SoC (Silicon Image ядро графического процессора SM750) | Только для KMS | |
| lima | 5.2 | ARM Mali 4xx GPU | ||
| panfrost | 5.2 | ARM Mali Txxx (Midgard) и Gxx (Bifrost) GPU |
Также есть ряд драйверов под старые, обсол Электронное оборудование подробно описано в следующей таблице для исторических целей. Некоторые из них все еще остались в коде ядра, а другие уже удалены.
| Драйвер | время с ядра | Поддерживаемое оборудование | Состояние / Примечания |
|---|---|---|---|
| гамма | 2.3.18 | 3Dlabs GLINT GMX 2000 | Удалено с версии 2.6.14 |
| ffb | 2.4 | Creator / Creator3D (используется Sun Microsystems Ultra рабочие станции) | Удалено с версии 2.6.21 |
| tdfx | 2.4 | 3dfx Banshee / Voodoo3 + | |
| mga | 2.4 | Matrox G200 / G400 / G450 | |
| r128 | 2.4 | ATI Rage 128 | |
| i810 | 2.4 | Intel i810 | |
| sis | 2.4.17 | SiS 300 / 630/540 | |
| i830 | 2.4.20 | Intel 830M / 845G / 852GM / 855GM / 865G | Удалено с 2.6.39 (заменено драйвером i915) |
| через | 2.6.13 | VIA Unichrome / Unichrome Pro | |
| savage | 2.6.14 | S3 Graphics Savage 3D / MX / IX / 4 / SuperSavage / Pro / Twister |
Менеджер прямого рендеринга используется в ядре Linux, а его исходный код находится в каталоге / drivers / gpu / drmкода Linux. Сопровождающим подсистемы является Дэйв Эрли, другие специалисты по сопровождению заботятся о конкретных драйверах. Как обычно при разработке ядра Linux, субмастерны DRM и участники отправляют свои патчи с новыми функциями и исправлениями ошибок основному разработчику DRM, который интегрирует их в свой собственный репозиторий Linux. Сопровождающий DRM, в свою очередь, отправляет все эти исправления, которые готовы к использованию, Линусу Торвальдсу всякий раз, когда будет выпущена новая версия Linux. Торвальдс, как главный сопровождающий всего ядра, держит последнее слово за то, подходит ли патч для включения в ядро.
По историческим причинам исходный код библиотеки libdrm поддерживается в рамках проекта Mesa.
В 1999 году, когда разрабатывая DRI для XFree86, компания Precision Insight создала первую версию DRM для видеокарт 3dfx как ядро Linux патч включен в исходный код Меса. Позже в том же году код DRM был встроен в ядро Linux 2.3.18 в каталоге / drivers / char / drm /для символьных устройств. В последующие годы поддерживаемых видеокарт росло. Когда с января 2001 года был выпущен Linux 2.4.0, в дополнение к картам 3dfx Voodoo3 уже была поддержка Creative Labs GMX 2000, Intel i810, Matrox G200 / G400 и ATI Rage 128, и этот список расширился в серии 2.4.x, серами для карт ATI Radeon, некоторые видеокарт SiS, Intel 830M и встроенных графических процессоров.
Разделение DRM на два компонента, ядро DRM и драйвер DRM, названное разделением ядра DRM / индивидуальности, было выполнено во второй половине 2004 года и объединено в версию ядра 2.6.11. Это разделение нескольким драйверам DRM для нескольких устройств работать одновременно, открывать путь к поддержке нескольких графических процессоров.
Идея link весь код настройки видеорежима в одном месте внутри ядра была установлена в течение многих лет, но производители видеокарт внеддали, что способ установить режим - это использовать процедуры сами по себе и установлен в Video BIOS Каждой видеокарты. Такой код должен был быть создан с использованием x86 реального режима, что предотвращает его запуск ядром, работающим в защищенном режиме. Ситуация изменилась, когда Люк Верхаген и другие разработчики нашли способ сделать настройку режима изначально, а не на основе BIOS, что это можно сделать, используя нормальный код ядра, и заложив основу для того, что станет настройкой режима ядра. В мае 2007 года Джесси Барнс (Intel ) опубликовал первое предложение по API настройки режима DRM и выполнить настройки режима для графических процессоров Intel в драйвере i915 DRM. В декабре 2007 года Джером Глисс добавил код режима для карт ATI в драйвер DRM radeon. Работа над API и драйверами продолжалась в течение 2008 г., но была отложена из-за необходимости наличия диспетчера памяти также в тесте для обработки буферов кадра.
Октябрь 2008 г. ядро Linux 2.6.27 принесло серьезный ущерб реорганизация исходного кода перед некоторыми дополнительными изменениями. Дерево исходного кода DRM было перемещено в собственный исходный каталог / drivers / gpu / drm /, а различные драйверы были перемещены в свои собственные подкаталоги. Заголовки также были перемещены в новый каталог /include/drm.
Возрастающая сложность управления видеопамятью привела к нескольким подходам к этой проблеме. Первой попыткой был менеджер памяти карт трансляции (TTM), пример Томасом Хеллстромом (Tungsten Graphics ) в сотрудничестве с Эриком Анхолтом (Intel) и Дэйвом Эйрли (Red Hat ). TTM был предложен для включения в ядро 2.6.25 в ноябре 2007 г. и снова в мае 2008 г., но от него отказались воспользоваться новым подходом под названием Graphics Execution Manager (GEM). GEM был впервые разработан Кейтом Паккардом и Эриком Анхолтом из Intel в качестве более простого решения для управления памятью для их драйвера i915. GEM был интегрирован в ядро Linux версии 2.6.28, выпущенный в декабре 2008 года. Между тем, TTM пришлось ждать до сентября 2009 года, чтобы окончательно объединиться с Linux 2.6.31 в соответствии с требованиями нового драйвера Radeon KMS DRM.
Имея управление памятью для обработки буферных объектов, разработчики DRM наконец смогли добавить ядро уже готовый API и код для настройки режима . Этот расширенный API называется настройкой режима режима (KMS), драйверы, реализующие его, часто называют драйверами KMS. В марте 2009 года KMS был объединен с ядром Linux версии 2.6.29 вместе с поддержкой KMS для драйвера i915. KMS API доступен для программно пользовательского пространства, начиная с libdrm 2.4.3. Драйвер пользовательского пространства X.Org DDX для видеокарт Intel также был первым, кто использовал новые API-интерфейсы GEM и KMS. Поддержка KMS для драйвера DRM radeon была добавлена в Linux 2.6.31 от сентября 2009 г. Новый драйвер KMS radeon использовал диспетчер памяти TTM, но предоставил GEM-совместимые интерфейсы и ioctls вместо интерфейса TTM.
С 2006 г. проект nouveau разрабатывал бесплатное программное обеспечение DRM-драйвер для графических процессоров NVIDIA вне официального ядра Linux. В 2010 году исходный код nouveau был объединен с Linux 2.6.33 в качестве экспериментального драйвера. На момент слияния драйвер уже преобразован в KMS, и для GEM API он использовал TTM в качестве диспетчера памяти.
Новый KMS API, включая GEM API, стал вехой в разработке DRM, но это не помешало совершенствованию API в последующие годы. KMS получил поддержку переворачивания страниц в сочетании с асинхронными уведомлениями VBLANK в Linux 2.6.33 - только для драйвера i915, radeon и nouveau добавили его позже, в выпуске Linux 2.6.38. Новый интерфейс перелистывания страниц был добавлен в libdrm 2.4.17. В начале 2011 года, во время цикла выпуска Linux 2.6.39, в KMS API были добавлены так называемые немые буферы - аппаратно-независимый способ обработки простых буферов, пригодных для использования в качестве буферов кадра. Цель заключалась в том, чтобы упростить приложения, такие как Плимут, не нужно использовать специальные ускоренные операции, используемые специфичными для драйвера ioctl. Эта функция была предоставлена libdrm начиная с версии 2.4.25. Позже в том же году он также получил новый основной тип объектов - самолеты. Плоскости были разработаны для представления аппаратных оверлеев, поддерживаемых механизмом сканирования. Поддержка Plane была добавлена в Linux 3.3. и libdrm 2.4.30. Еще одна концепция, добавленная в API - в выпусках Linux 3.5 и libdrm 2.4.36 - это общие свойства объекта, метод добавления общих значений к любому объекту KMS. Свойства особенно полезны для установки особого поведения или функций для таких объектов, как CRTC и плоскости.
Раннее испытание концепции разгрузки графического процессора между драйверами DRM было разработано Дэйвом Эйрли в 2010 году. Эйрли пытался имитировать технологию NVIDIA Optimus, он решил назвать ее «ПРАЙМ» ". Эйрли возобновил свою работу над PRIME в конце 2011 года, но на основе нового механизма разделения буфера DMA-BUF Базовая инфраструктура DMA-BUF PRIME завершена в марте 2012 года и объединена с выпуском Linux 3.4, а также с libdrm 2.4.34. Позже, во время выпуска Linux 3.5, несколько драйверов DRM реализовали поддержку PRIME, в том В том числе i915 для карт Intel, Radeon для карт AMD и nouveau для карт NVIDIA.
В последние годы DRM API постепенно расширяется новыми и улучшенными функциями. В 2013 году в рамках GSoC Дэвид Херрманн разработал функцию Несколько узлов рендеринга. Это был добавлен в ядро Linux версии 3.12 в экспериментальной функции, поддерживаемой драйверами i915, radeon и nouveau, по умолчанию, начиная с Linux 3.17. В 2014 году Мэтт Ропер (Intel) разработал концепцию универсального плоскости остей (или унифицированных плоскостей), согласно которой фреймбуферы (вторичные плоскости), наложения (вторичные плоскости) и курс (плоскость курса) рассматривают как один тип объекта с унифицированным API. Поддержка универсальных плоскостей обеспечивает более согласованный API DRM с меньшим более общим ioctls. Чтобы обеспечить обратную совместимость API , эта функция предоставляется ядром DRM как дополнительная возможность, предоставленная драйвером DRM. Поддержка универсальной плоскости дебютировала в Linux 3.15 и libdrm 2.4.55. Несколько драйверов, например Intel i915, уже реализовали это.
Самым последним усовершенствованием API DRM является настройка API атомарного режима, который привносит атомарность в операции режима и перелистывания страниц на устройстве DRM. Идея атомарного API для режима была впервые предложена в начале 2012 года. Вилле Сирьяля (Intel) взял на себя задачу разработки и реализации такого атомарного API. Основываясь на своей работе, Роб Кларк (Texas Instruments ) использовал аналогичный подход, стремясь реализовать атомарные перелистывания страниц. Позже в 2013 году обе предлагаемые функции были объединены в одну с использованием одного ioctl для разных задач. Функция должна быть дождаться объединения поддержки универсальных самолетов в середине 2014 года. Во второй половине 2014 года атомарный код был значительно улучшен Дэниелом Веттером (Intel) и другими разработчиками DRM, чтобы облегчить переходное использование драйверов KMS на новую атомарную структуру. Вся эта работа была наконец объединена в выпусках Linux 3.19 и Linux 4.0 и включены по умолчанию, начиная с Linux 4.2. libdrm представила новый атомарный API начиная с версии 2.4.62. Несколько драйверов уже преобразованы в новый атомарный API. В 2018 году в ядро Linux было добавлено десять новых драйверов DRM, основанных на новой атомарной модели.
Подсистема ядра Direct Rendering Manager автоматически была использована для использования с новым Инфраструктура прямого рендеринга сервера представления XFree86 4.0, позже унаследованным его преемником, сервером X.Org. Следовательно, пользователями DRM были клиенты DRI, которые связаны с реализацией OpenGL с аппаратным ускорением, которая находится в библиотеке Mesa 3D, а также с самим X-сервером. В настоящее время используется DRM также используется композиторами Wayland, включая эталонный композитор Weston. kmscon - это реализация консоли, которая запускается в пользовательском пространстве с использованием DRM KMS.
В 2015 году версия 358.09 (бета) проприетарного драйвера Nvidia GeForce получила поддержку для настройки интерфейса режима DRM, реализованного в виде нового большого двоичного объекта ядра с именем nvidia-modeset.ko. Этот новый компонент драйвера работает вместе с модулем ядра nvidia.koдля программирования механизма отображения (есть контроллер дисплея) графического процессора.
портал Linux 
Портал бесплатного программного обеспечения с открытым исходным кодом 