stringtranslate.com

Менеджер прямого рендеринга

Диспетчер прямого рендеринга ( DRM ) — это подсистема ядра Linux , отвечающая за взаимодействие с графическими процессорами современных видеокарт . DRM предоставляет API , который программы пользовательского пространства могут использовать для отправки команд и данных в графический процессор и выполнения таких операций, как настройка режима дисплея . DRM был впервые разработан как компонент пространства ядра инфраструктуры прямого рендеринга X Server [1] , но с тех пор он использовался другими альтернативами графического стека, такими как Wayland , а также автономными приложениями и библиотеками, такими как SDL2 и Kodi .

Программы пользовательского пространства могут использовать DRM API, чтобы управлять графическим процессором для выполнения аппаратного ускорения 3D-рендеринга и декодирования видео , а также вычислений GPGPU .

Обзор

В ядре Linux уже был API под названием fbdev , используемый для управления кадровым буфером графического адаптера [2] , но его нельзя было использовать для удовлетворения потребностей современного видеооборудования на базе графического процессора с 3D-ускорением. Эти устройства обычно требуют настройки и управления очередью команд в собственной памяти для отправки команд на графический процессор, а также требуют управления буферами и свободным пространством в этой памяти. [3] Первоначально программы пользовательского пространства (такие как X-сервер ) напрямую управляли этими ресурсами, но обычно они действовали так, как если бы они были единственными, кто имел к ним доступ. Когда две или более программы пытались одновременно управлять одним и тем же оборудованием и настраивать свои ресурсы каждая по-своему, в большинстве случаев это заканчивалось катастрофически. [3]

DRM обеспечивает одновременный доступ нескольких программ к 3D-видеокарте, избегая конфликтов

Менеджер прямого рендеринга был создан, чтобы позволить нескольким программам совместно использовать ресурсы видеооборудования. [4] DRM получает эксклюзивный доступ к графическому процессору и отвечает за инициализацию и поддержание очереди команд, памяти и любых других аппаратных ресурсов. Программы, желающие использовать графический процессор, отправляют запросы в DRM, который выступает в качестве арбитра и старается избежать возможных конфликтов.

Область применения DRM с годами расширялась и теперь охватывает больше функций, ранее обрабатывавшихся программами пользовательского пространства, таких как управление кадровым буфером и настройка режима , объекты совместного использования памяти и синхронизация памяти. [5] [6] Некоторым из этих расширений были присвоены конкретные имена, например, «Диспетчер графического выполнения» (GEM) или «Настройка режима ядра» (KMS), и эта терминология преобладает, когда конкретно упоминаются предоставляемые ими функциональные возможности. Но на самом деле они являются частью всей подсистемы DRM ядра.

Тенденция включения в компьютер двух графических процессоров — дискретного и интегрированного — привела к новым проблемам, таким как переключение графических процессоров , которые также необходимо было решать на уровне DRM. Чтобы соответствовать технологии Nvidia Optimus , DRM была снабжена возможностями разгрузки графического процессора, называемыми PRIME. [7]

Архитектура программного обеспечения

Процесс использования диспетчера прямого рендеринга ядра Linux для доступа к видеокарте с 3D-ускорением.

Диспетчер прямого рендеринга находится в пространстве ядра , поэтому программы пользовательского пространства должны использовать системные вызовы ядра для запроса его услуг. Однако DRM не определяет свои собственные системные вызовы. Вместо этого он следует принципу Unix « все есть файл », чтобы предоставлять доступ к графическим процессорам через пространство имен файловой системы, используя файлы устройств в /devиерархии. Каждый графический процессор, обнаруженный DRM, называется устройством DRM , и для взаимодействия с ним создается файл устройства (где X — порядковый номер). [8] [9] Программы пользовательского пространства, которые хотят взаимодействовать с графическим процессором, должны открыть этот файл и использовать вызовы ioctl для связи с DRM. Разные ioctls соответствуют разным функциям DRM API ./dev/dri/cardX

Библиотека под названием libdrm была создана для облегчения интерфейса программ пользовательского пространства с подсистемой DRM. Эта библиотека представляет собой просто оболочку , которая предоставляет функцию , написанную на C , для каждого ioctl API DRM, а также константы, структуры и другие вспомогательные элементы. [10] Использование libdrm не только позволяет избежать прямого доступа к интерфейсу ядра приложениям, но и предоставляет обычные преимущества повторного использования и совместного использования кода между программами.

Подробности архитектуры Direct Rendering Manager: ядро ​​DRM и драйвер DRM (включая GEM и KMS), взаимодействующие с libdrm.

DRM состоит из двух частей: общего «ядра DRM» и специального («драйвер DRM») для каждого типа поддерживаемого оборудования. [11] Ядро DRM обеспечивает базовую структуру, в которой могут регистрироваться различные драйверы DRM, а также предоставляет пользовательскому пространству минимальный набор ioctl с общими, независимыми от оборудования функциями. [8] Драйвер DRM, с другой стороны, реализует аппаратно-зависимую часть API, специфичную для типа поддерживаемого графического процессора; он должен обеспечить реализацию остальных ioctl, не охватываемых ядром DRM, но также может расширять API, предлагая дополнительные ioctl с дополнительной функциональностью, доступной только на таком оборудовании. [8] Когда конкретный драйвер DRM предоставляет расширенный API, libdrm в пользовательском пространстве также расширяется за счет дополнительной библиотеки libdrm- driver , которая может использоваться пользовательским пространством для взаимодействия с дополнительными ioctls.

API

Ядро DRM экспортирует несколько интерфейсов в приложения пользовательского пространства, которые обычно предназначены для использования через соответствующие libdrmфункции-оболочки. Кроме того, драйверы экспортируют интерфейсы, специфичные для устройства, для использования драйверами пользовательского пространства и приложениями, поддерживающими устройства, через файлы ioctls и sysfs . Внешние интерфейсы включают в себя: сопоставление памяти, управление контекстом, операции DMA , управление AGP , управление vblank , управление ограждением, управление памятью и управление выводом.

DRM-Master и DRM-Auth

В API DRM есть несколько операций (ioctls), использование которых либо в целях безопасности, либо из-за проблем параллелизма должно быть ограничено одним процессом пользовательского пространства для каждого устройства. [8] Чтобы реализовать это ограничение, DRM ограничивает вызов таких ioctl только процессом, считающимся «главным» устройства DRM, обычно называемым DRM-Master . Только один из всех процессов, у которых открыт узел устройства, будет иметь дескриптор файла , помеченный как главный, в частности, первый, вызывающий SET_MASTER ioctl. Любая попытка использовать один из этих ограниченных ioctl, не являясь DRM-Master, вернет ошибку. Процесс также может отказаться от своей главной роли и позволить другому процессу получить ее, вызвав DROP_MASTER ioctl./dev/dri/cardX

X -сервер — или любой другой сервер отображения — обычно представляет собой процесс, который получает статус DRM-Master в каждом устройстве DRM, которым он управляет, обычно когда он открывает соответствующий узел устройства во время своего запуска, и сохраняет эти привилегии в течение всего графического сеанса до тех пор, пока оно заканчивается или умирает.

Для остальных процессов пользовательского пространства есть другой способ получить привилегию на вызов некоторых ограниченных операций на устройстве DRM, называемом DRM-Auth . По сути, это метод аутентификации на устройстве DRM, чтобы доказать ему, что процесс имеет разрешение DRM-Master на получение таких привилегий. Процедура состоит из: [12] : 13 

Менеджер графического выполнения

Из-за увеличения размера видеопамяти и растущей сложности графических API, таких как OpenGL , стратегия повторной инициализации состояния видеокарты при каждом переключении контекста была слишком дорогой с точки зрения производительности. Кроме того, современные настольные компьютеры Linux нуждались в оптимальном способе совместного использования внеэкранных буферов с менеджером композиции . Эти требования привели к разработке новых методов управления графическими буферами внутри ядра. Одним из таких методов стал Graphics Execution Manager (GEM ) . [6]

GEM предоставляет API с явными примитивами управления памятью . [6] С помощью GEM программа пользовательского пространства может создавать, обрабатывать и уничтожать объекты памяти, находящиеся в видеопамяти графического процессора. Эти объекты, называемые «объектами GEM» [14] , являются постоянными с точки зрения программы пользовательского пространства, и их не нужно перезагружать каждый раз, когда программа восстанавливает контроль над графическим процессором. Когда программе пользовательского пространства требуется фрагмент видеопамяти (для хранения кадрового буфера , текстуры или любых других данных, необходимых графическому процессору [15] ), она запрашивает выделение у драйвера DRM с помощью GEM API. Драйвер DRM отслеживает используемую видеопамять и может выполнить запрос, если есть свободная память, возвращая «дескриптор» пользовательского пространства для дальнейшего обращения к выделенной памяти в последующих операциях. [6] [14] GEM API также предоставляет операции для заполнения буфера и его освобождения, когда он больше не нужен. Память из невыпущенных дескрипторов GEM восстанавливается, когда процесс пользовательского пространства закрывает дескриптор файла устройства DRM — намеренно или по причине его завершения. [16]

GEM также позволяет двум или более процессам пользовательского пространства , использующим одно и то же устройство DRM (следовательно, один и тот же драйвер DRM), совместно использовать объект GEM. [16] Дескрипторы GEM — это локальные 32-битные целые числа, уникальные для процесса, но повторяющиеся в других процессах, поэтому не подходящие для совместного использования. Что необходимо, так это глобальное пространство имен, и GEM предоставляет его посредством использования глобальных дескрипторов, называемых именами GEM . Имя GEM относится к одному и только одному объекту GEM, созданному на одном устройстве DRM одним и тем же драйвером DRM с использованием уникального 32-битного целого числа . GEM предоставляет операцию flink для получения имени GEM из дескриптора GEM. [16] [12] : 16  Затем процесс может передать это имя GEM (32-битное целое число) другому процессу, используя любой доступный механизм IPC . [12] : 15  Имя GEM может использоваться процессом-получателем для получения локального дескриптора GEM, указывающего на исходный объект GEM.

К сожалению, использование имен GEM для совместного использования буферов небезопасно. [12] : 16  [17] [18] Вредоносный сторонний процесс, обращающийся к тому же устройству DRM, может попытаться угадать имя GEM буфера, совместно используемого двумя другими процессами, просто проверяя 32-битные целые числа. [19] [18] Как только имя GEM найдено, его содержимое может быть доступно и изменено, нарушая конфиденциальность и целостность информации буфера. Этот недостаток был преодолен позже за счет введения поддержки DMA-BUF в DRM, поскольку DMA-BUF представляет буферы в пользовательском пространстве в виде файловых дескрипторов, которые можно безопасно совместно использовать .

Еще одной важной задачей любой системы управления видеопамятью, помимо управления пространством видеопамяти, является синхронизация памяти между графическим процессором и процессором. Современные архитектуры памяти очень сложны и обычно включают в себя различные уровни кэшей для системной памяти, а иногда и для видеопамяти. Следовательно, менеджеры видеопамяти также должны обеспечивать согласованность кэша , чтобы гарантировать согласованность данных, совместно используемых ЦП и ГП. [20] Это означает, что часто внутренние функции управления видеопамятью сильно зависят от аппаратных особенностей графического процессора и архитектуры памяти и, следовательно, зависят от драйвера. [21]

GEM изначально был разработан инженерами Intel как менеджер видеопамяти для драйвера i915. [20] Семейство Intel GMA 9xx представляет собой интегрированные графические процессоры с единой архитектурой памяти (UMA), в которой графический процессор и процессор совместно используют физическую память, а выделенная видеопамять отсутствует. [22] GEM определяет «домены памяти» для синхронизации памяти, и хотя эти домены памяти не зависят от графического процессора, [6] они специально разработаны с учетом архитектуры памяти UMA, что делает их менее подходящими для других архитектур памяти, например, с отдельная видеопамять. По этой причине другие драйверы DRM решили предоставить программам пользовательского пространства API GEM, но внутри они реализовали другой менеджер памяти, лучше подходящий для их конкретного оборудования и архитектуры памяти. [23]

GEM API также предоставляет ioctls для управления потоком выполнения (буферы команд), но они специфичны для Intel и могут использоваться с графическими процессорами Intel i915 и более поздних версий. [6] Ни один другой драйвер DRM не пытался реализовать какую-либо часть GEM API, кроме ioctls, предназначенного для управления памятью.

Карты таблиц перевода

Карты таблиц трансляции (TTM) — это название универсального менеджера памяти для графических процессоров, который был разработан до GEM. [5] [14] Он был специально разработан для управления различными типами памяти, к которым может иметь доступ графический процессор, включая выделенную видеопамять (обычно установленную в видеокарте) и системную память , доступную через блок управления памятью ввода-вывода, называемый графикой. Таблица переназначения адресов (GART). [5] TTM также должен обрабатывать те части видеопамяти, которые не доступны напрямую ЦП, и делать это с максимально возможной производительностью, учитывая, что графические приложения пользовательского пространства обычно работают с большими объемами видеоданных. Еще одним важным вопросом было поддержание согласованности между различными задействованными воспоминаниями и кэшами.

Основная концепция TTM — это «буферные объекты», области видеопамяти, которые в какой-то момент должны быть доступны графическому процессору. [5] Когда графическому приложению пользовательского пространства требуется доступ к определенному объекту буфера (обычно для заполнения его содержимым), TTM может потребовать переместить его в тип памяти, адресуемый ЦП. Дальнейшие перемещения — или операции сопоставления GART — могут произойти, когда графическому процессору требуется доступ к буферному объекту, но он еще не находится в адресном пространстве графического процессора. Каждая из этих операций перемещения должна обрабатывать любые связанные данные и проблемы согласованности кэша. [5]

Еще одна важная концепция ТТМ — ограждения . По сути, ограждения — это механизм управления параллелизмом между процессором и графическим процессором. [24] Ограждение отслеживает, когда объект буфера больше не используется графическим процессором, как правило, для уведомления любого процесса пользовательского пространства, имеющего к нему доступ. [5]

Тот факт, что TTM пыталась управлять всеми видами архитектур памяти, в том числе с выделенной видеопамятью и без нее, подходящим способом, а также обеспечить все мыслимые функции диспетчера памяти для использования с любым типом оборудования, привел к чрезмерно сложной задаче. решение с API, намного большим, чем необходимо. [24] [14] Некоторые разработчики DRM считали, что он не будет хорошо сочетаться с каким-либо конкретным драйвером, особенно с API. Когда GEM стал более простым менеджером памяти, его API было предпочтительнее API TTM. Но некоторые разработчики драйверов посчитали, что подход, используемый TTM, больше подходит для дискретных видеокарт с выделенной видеопамятью и IOMMU, поэтому они решили использовать TTM внутри себя, одновременно предоставляя свои буферные объекты как объекты GEM и, таким образом, поддерживая GEM API. [23] Примерами текущих драйверов, использующих TTM в качестве диспетчера внутренней памяти, но предоставляющих GEM API, являются драйвер Radeon для видеокарт AMD и драйвер nouveau для видеокарт NVIDIA.

Совместное использование буфера DMA и PRIME

API совместного использования буферов DMA (часто сокращенно DMA-BUF) — это внутренний API ядра Linux , разработанный для обеспечения общего механизма для совместного использования буферов DMA между несколькими устройствами, возможно, управляемыми различными типами драйверов устройств. [25] [26] Например, устройство Video4Linux и графический адаптер могут совместно использовать буферы через DMA-BUF, чтобы добиться нулевого копирования данных видеопотока, создаваемого первым и потребляемого последним. Любой драйвер устройства Linux может реализовать этот API как экспортер, как пользователь (потребитель) или и то, и другое.

Эта функция была впервые использована в DRM для реализации PRIME, решения для разгрузки графического процессора, которое использует DMA-BUF для совместного использования результирующих кадровых буферов между драйверами DRM дискретного и встроенного графического процессора. [27] : 13  Важной особенностью DMA-BUF является то, что общий буфер представляется пользовательскому пространству как файловый дескриптор . [14] [12] : 17  Для разработки PRIME в DRM API были добавлены два новых ioctl: один для преобразования локального дескриптора GEM в файловый дескриптор DMA-BUF, а другой для прямо противоположной операции.

Эти два новых ioctl позже были повторно использованы как способ исправить внутреннюю небезопасность совместного использования буфера GEM. [12] : 17  В отличие от имен GEM, дескрипторы файлов невозможно угадать (они не являются глобальным пространством имен), и операционные системы Unix предоставляют безопасный способ передать их через сокет домена Unix, используя семантику SCM_RIGHTS. [14] [28] : 11  Процесс, который хочет использовать объект GEM совместно с другим процессом, может преобразовать свой локальный дескриптор GEM в дескриптор файла DMA-BUF и передать его получателю, который, в свою очередь, может получить свой собственный дескриптор GEM от полученный дескриптор файла. [12] : 16  Этот метод используется DRI3 для совместного использования буферов между клиентом и X-сервером [29] , а также Wayland .

Настройка режима ядра

В пользовательском пространстве должен быть «мастер DRM», эта программа имеет эксклюзивный доступ к KMS.

Для правильной работы видеокарта или графический адаптер должны установить режим — сочетание разрешения экрана , глубины цвета и частоты обновления — который находится в диапазоне значений, поддерживаемых самой видеокартой и подключенным экраном дисплея . Эта операция называется установкой режима [ 30] и обычно требует прямого доступа к графическому оборудованию, то есть возможности записи в определенные регистры контроллера дисплея видеокарты . [31] [32] Операцию настройки режима необходимо выполнить перед началом использования кадрового буфера , а также когда режим требуется изменить приложению или пользователю.

Раньше программы пользовательского пространства, которые хотели использовать графический буфер кадров, также отвечали за выполнение операций по настройке режима [3] , и поэтому их нужно было запускать с привилегированным доступом к видеооборудованию. В операционных системах типа Unix наиболее ярким примером был X-сервер , и его реализация настройки режима находилась в драйвере DDX для каждого конкретного типа видеокарты. [33] Этот подход, позже названный «Настройка режима пользовательского пространства» или UMS, [34] [35] создает несколько проблем. [36] [30] Это не только нарушает изоляцию, которую операционные системы должны обеспечивать между программами и оборудованием, что вызывает проблемы как со стабильностью, так и с безопасностью, но также может привести к тому, что графическое оборудование окажется в несогласованном состоянии, если две или более программы пользовательского пространства попытаются выполнить какие-либо действия. одновременно с установкой режима. Чтобы избежать этих конфликтов, X-сервер стал практически единственной программой пользовательского пространства, которая выполняла операции установки режима; остальные программы пользовательского пространства полагались на X-сервер для установки соответствующего режима и выполнения любых других операций, связанных с установкой режима. Первоначально настройка режима выполнялась исключительно во время запуска X-сервера, но позже X-сервер получил возможность делать это во время работы. [37] Расширение XFree86-VidModeExtension было введено в XFree86 3.1.2, чтобы позволить любому X-клиенту запрашивать модель (разрешение) изменений на X-сервере. [38] [39] Расширение VidMode позже было заменено более общим расширением XRandR .

Однако это был не единственный код, выполняющий настройку режима в системе Linux . В процессе загрузки системы ядро ​​Linux должно установить минимальный текстовый режим для виртуальной консоли (на основе стандартных режимов, определенных расширениями VESA BIOS ). [40] Кроме того, драйвер кадрового буфера ядра Linux содержал код настройки режима для настройки устройств кадрового буфера. [2] Чтобы избежать конфликтов настроек режима, сервер XFree86 — а позже и сервер X.Org — обрабатывал случай, когда пользователь переключался из графической среды на текстовую виртуальную консоль , сохраняя состояние настройки режима и восстанавливая его при пользователь переключился обратно на X. [41] Этот процесс вызывал раздражающее мерцание при переходе, а также может привести к сбою, что приведет к повреждению или непригодности вывода на экран. [42]

Подход к настройке режима пользовательского пространства также вызвал другие проблемы: [43] [42]

Чтобы решить эти проблемы, код установки режима был перенесен в одно место внутри ядра, а именно в существующий модуль DRM. [36] [37] [44] [42] [43] Тогда каждый процесс, включая X-сервер, должен иметь возможность командовать ядром для выполнения операций установки режима, и ядро ​​​​гарантирует, что одновременные операции не привести к противоречивому состоянию. Новый API ядра и код, добавленные в модуль DRM для выполнения этих операций по настройке режима, получили название « Настройка режима ядра» (KMS). [30]

Настройка режима ядра дает несколько преимуществ. Самым неотложным является, конечно, удаление дублирующего кода настройки режима как из ядра (консоль Linux, fbdev), так и из пользовательского пространства (драйверы X Server DDX). KMS также упрощает написание альтернативных графических систем, которым теперь не нужно реализовывать собственный код установки режима. [42] [43] Обеспечивая централизованное управление режимами, KMS решает проблемы мерцания при переключении между консолью и X, а также между различными экземплярами X (быстрое переключение пользователей). [41] [44] Поскольку он доступен в ядре, его также можно использовать в начале процесса загрузки, что позволяет избежать мерцания из-за изменения режима на этих ранних стадиях.

Тот факт, что KMS является частью ядра, позволяет ему использовать ресурсы, доступные только в пространстве ядра, например прерывания . [45] Например, восстановление режима после процесса приостановки/возобновления значительно упрощается, поскольку управляется самим ядром, и, кстати, повышает безопасность (больше не нужны инструменты пользовательского пространства, требующие root-прав). Ядро также позволяет легко подключать новые устройства отображения, решая давнюю проблему. [45] Настройка режима также тесно связана с управлением памятью, поскольку кадровые буферы по сути являются буферами памяти, поэтому настоятельно рекомендуется тесная интеграция с диспетчером графической памяти. Это основная причина, по которой код установки режима ядра был включен в DRM, а не как отдельная подсистема. [44]

Чтобы избежать нарушения обратной совместимости API DRM, настройка режима ядра предоставляется в качестве дополнительной функции некоторых драйверов DRM. [46] Любой драйвер DRM может предоставить флаг DRIVER_MODESET при регистрации в ядре DRM, чтобы указать, что он поддерживает KMS API. [8] Драйверы, реализующие настройку режима ядра, часто называют драйверами KMS , чтобы отличить их от устаревших драйверов DRM без KMS.

KMS был принят до такой степени, что некоторые драйверы, в которых отсутствует 3D-ускорение (или для которых поставщик оборудования не хочет его раскрывать или реализовывать), тем не менее реализуют API KMS без остальной части API DRM, позволяя серверам отображения (например, Wayland ), чтобы легко бегать. [47] [48]

Модель устройства KMS

KMS моделирует и управляет устройствами вывода как серией абстрактных аппаратных блоков, обычно встречающихся в конвейере вывода дисплея контроллера дисплея . Эти блоки: [49]

Атомный дисплей

В последние годы предпринимались постоянные усилия по обеспечению атомарности некоторых регулярных операций, связанных с API KMS, в частности, операций настройки режима и перелистывания страниц . [33] [52] Этот расширенный API KMS называется Atomic Display (ранее известный как атомарная настройка режима и атомарный или ядерный переворот страницы ).

Целью атомарной настройки режима является обеспечение правильного изменения режима в сложных конфигурациях с множеством ограничений, избегая промежуточных шагов, которые могут привести к нестабильному или недействительному состоянию видео; [52] это также позволяет избежать рискованных состояний видео, когда необходимо отменить неудачный процесс установки режима («откат»). [53] : 9  Атомная настройка режима позволяет заранее узнать, подходит ли определенная конкретная конфигурация режима, предоставляя возможности тестирования режима. [52] Когда атомарный режим протестирован и его достоверность подтверждена, его можно применить с помощью одной неделимой (атомарной) операции фиксации . Операции тестирования и фиксации выполняются одним и тем же новым ioctl с разными флагами.

С другой стороны, атомарное переворот страниц позволяет обновлять несколько плоскостей на одном выходе (например, основную плоскость, плоскость курсора и, возможно, некоторые наложения или вторичные плоскости), все синхронизируются в пределах одного и того же интервала VBLANK , обеспечивая правильное отображение без разрывов. [53] : 9,14  [52] Это требование особенно актуально для мобильных и встроенных контроллеров дисплеев, которые, как правило, используют несколько плоскостей/наложений для экономии энергии.

Новый атомарный API основан на старом API KMS. Он использует ту же модель и объекты (CRTC, энкодеры, соединители, плоскости и т. д.), но с растущим числом свойств объекта, которые можно изменить. [52] Атомарная процедура основана на изменении соответствующих свойств для создания состояния, которое мы хотим протестировать или зафиксировать. Свойства, которые мы хотим изменить, зависят от того, хотим ли мы выполнить настройку режима (в основном свойства CRTC, кодировщиков и соединителей) или переворот страниц (обычно свойства плоскостей). ioctl один и тот же для обоих случаев, разница заключается в списке свойств, передаваемых в каждом из них. [54]

Узлы рендеринга

В исходном API DRM устройство DRM используется как для привилегированных (настройка режима, другое управление отображением), так и для непривилегированных операций (рендеринг, вычисления GPGPU ). [9] По соображениям безопасности для открытия связанного файла устройства DRM требуются специальные привилегии, «эквивалентные привилегиям root». [55] Это приводит к архитектуре, в которой только некоторые надежные программы пользовательского пространства (X-сервер, графический наборщик и т. д.) имеют полный доступ к API DRM, включая привилегированные части, такие как API-интерфейс modeset. Другие приложения пользовательского пространства, которые хотят отображать или выполнять вычисления GPGPU, должны быть разрешены владельцем устройства DRM («Master DRM») посредством использования специального интерфейса аутентификации. [56] Затем аутентифицированные приложения могут отображать или выполнять вычисления с использованием ограниченной версии API DRM без привилегированных операций. Такая конструкция накладывает серьезное ограничение: всегда должен быть работающий графический сервер (X-сервер, наборщик Wayland и т. д.), действующий как DRM-Master устройства DRM, чтобы другим программам пользовательского пространства можно было разрешить использование устройстве, даже в случаях, когда не требуется графический дисплей, например вычисления GPGPU. [55] [56]/dev/dri/cardX

Концепция «узлов рендеринга» пытается решить эти сценарии, разделив API пользовательского пространства DRM на два интерфейса — один привилегированный и один непривилегированный — и используя отдельные файлы устройств (или «узлы») для каждого из них. [9] Для каждого найденного графического процессора соответствующий драйвер DRM — если он поддерживает функцию узлов рендеринга — создает файл устройства , называемый узлом рендеринга , в дополнение к основному узлу . [56] [9] Клиенты, использующие модель прямого рендеринга, и приложения, желающие воспользоваться преимуществами вычислительных возможностей графического процессора, могут делать это, не требуя дополнительных привилегий, просто открывая любой существующий узел рендеринга и отправляя операции графического процессора с использованием ограниченного подмножества. API DRM, поддерживаемого этими узлами, при условии, что у них есть разрешения файловой системы на открытие файла устройства. Серверы отображения, наборщики и любые другие программы, которым требуется API-интерфейс modeset или любая другая привилегированная операция, должны открыть стандартный основной узел, который предоставляет доступ к полному API DRM, и использовать его как обычно. Узлы рендеринга явно запрещают операцию перелистывания GEM , чтобы предотвратить совместное использование буфера с использованием небезопасных глобальных имен GEM; только файловые дескрипторы PRIME (DMA-BUF) могут использоваться для совместного использования буферов с другим клиентом, включая графический сервер. [9] [56]/dev/dri/renderDX/dev/dri/cardX

Аппаратная поддержка

DRM должен использоваться драйвером графического устройства пользовательского режима, например AMD Catalyst или Mesa 3D . Программы пользовательского пространства используют интерфейс системных вызовов Linux для доступа к DRM. DRM дополняет интерфейс системных вызовов Linux собственными системными вызовами. [57]

Подсистема Linux DRM включает в себя бесплатные драйверы с открытым исходным кодом для поддержки оборудования трех основных производителей графических процессоров для настольных компьютеров (AMD, NVIDIA и Intel), а также растущего числа мобильных графических процессоров и систем на кристалле (SoC). интеграторы. Качество каждого драйвера сильно варьируется в зависимости от степени сотрудничества со стороны производителя и других факторов.

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

Разработка

Менеджер прямого рендеринга разработан в ядре Linux , а его исходный код находится в /drivers/gpu/drmкаталоге исходного кода Linux. Сопровождающим подсистемы является Дэйв Эйрли, а за конкретные драйверы отвечают другие сопровождающие. [123] Как обычно при разработке ядра Linux, субподрядчики и участники DRM отправляют свои патчи с новыми функциями и исправлениями ошибок основному сопровождающему DRM, который интегрирует их в свой собственный репозиторий Linux . Сопровождающий DRM, в свою очередь, передает все эти исправления, готовые к использованию, Линусу Торвальдсу всякий раз, когда будет выпущена новая версия Linux. Торвальдс, как главный специалист по сопровождению всего ядра, оставляет за собой последнее слово в отношении того, подходит или нет патч для включения в ядро.

По историческим причинам исходный код библиотеки libdrm поддерживается под эгидой проекта Mesa . [124]

История

В 1999 году при разработке DRI для XFree86 компания Precision Insight создала первую версию DRM для видеокарт 3dfx в виде патча ядра Linux , включенного в исходный код Mesa . [125] Позже в том же году код DRM был включен в ядро ​​Linux 2.3.18 в каталоге для символьных устройств . [126] В последующие годы количество поддерживаемых видеокарт росло. Когда в январе 2001 года был выпущен Linux 2.4.0, в дополнение к картам 3dfx Voodoo3 уже поддерживались Creative Labs GMX 2000, Intel i810, Matrox G200/G400 и ATI Rage 128, [127] и этот список расширился в версии 2.4. x, с драйверами для карт ATI Radeon , некоторых видеокарт SiS, а также Intel 830M и последующих интегрированных графических процессоров./drivers/char/drm/

Разделение DRM на два компонента, ядро ​​DRM и драйвер DRM, называемое разделением ядра/личности DRM , было сделано во второй половине 2004 года [11] [128] и объединено в версию ядра 2.6.11. [129] Такое разделение позволило нескольким драйверам DRM для нескольких устройств работать одновременно, открывая путь к поддержке нескольких графических процессоров.

Идея разместить весь код настройки видеорежима в одном месте внутри ядра была признана в течение многих лет, [130] [131] , но производители видеокарт утверждали, что единственный способ выполнить настройку режима — это использовать процедуры предоставляются сами по себе и содержатся в Video BIOS каждой видеокарты. Такой код должен был выполняться в реальном режиме x86 , что предотвращало его вызов ядром, работающим в защищенном режиме . [44] Ситуация изменилась, когда Люк Верхаген и другие разработчики нашли способ выполнять настройку режима самостоятельно, а не на основе BIOS, [132] [44] показав, что это можно сделать, используя обычный код ядра и заложив основу. для того, что станет настройкой режима ядра . В мае 2007 года Джесси Барнс ( Intel ) опубликовал первое предложение по API настройки режима drm и работающую встроенную реализацию настройки режима для графических процессоров Intel в драйвере DRM i915. [42] В декабре 2007 года Джером Глисс начал добавлять собственный код настройки режима для карт ATI в драйвер DRM Radeon. [133] [134] Работа над API и драйверами продолжалась в течение 2008 года, но была отложена из-за необходимости наличия менеджера памяти также в пространстве ядра для обработки кадровых буферов. [135]

В октябре 2008 года ядро ​​Linux 2.6.27 претерпело серьезную реорганизацию исходного кода перед предстоящими значительными изменениями. Дерево исходного кода DRM было перемещено в отдельный исходный каталог /drivers/gpu/drm/, а различные драйверы были перемещены в свои подкаталоги. Заголовки также были перенесены в новый /include/drmкаталог. [136]

Возрастающая сложность управления видеопамятью привела к появлению нескольких подходов к решению этого вопроса. Первой попыткой стал менеджер памяти Translation Table Maps (TTM), разработанный Томасом Хеллстремом ( Tungsten Graphics ) в сотрудничестве с Эммой Анхольт (Intel) и Дэйвом Эйрли ( Red Hat ). [5] TTM предлагалось включить в основное ядро ​​2.6.25 в ноябре 2007 г., [5] и снова в мае 2008 г., но от него отказались в пользу нового подхода под названием Graphics Execution Manager (GEM). [24] GEM был впервые разработан Китом Паккардом и Эммой Анхольт из Intel как более простое решение для управления памятью для их драйвера i915. [6] GEM был хорошо принят и объединен с версией ядра Linux 2.6.28, выпущенной в декабре 2008 года. [137] Между тем, TTM пришлось ждать до сентября 2009 года, чтобы окончательно объединиться с Linux 2.6.31 в качестве требования новой Radeon. Драйвер KMS DRM. [138]

Имея управление памятью для обработки буферных объектов, разработчики DRM наконец смогли добавить в ядро ​​уже готовый API и код для настройки режима . Этот расширенный API называется настройкой режима ядра (KMS), а драйверы, которые его реализуют, часто называются драйверами KMS . В марте 2009 года KMS был объединен с ядром Linux версии 2.6.29, [30] [139] вместе с поддержкой KMS для драйвера i915. [140] API KMS доступен программам пользовательского пространства начиная с libdrm 2.4.3. [141] Драйвер пользовательского пространства X.Org DDX для видеокарт Intel также был первым, кто использовал новые API-интерфейсы GEM и KMS. [142] Поддержка KMS для драйвера radeon DRM была добавлена ​​в Linux 2.6.31, выпущенная в сентябре 2009 года. [143] [144] [145] Новый драйвер radeon KMS использовал диспетчер памяти TTM, но вместо этого предоставлял GEM-совместимые интерфейсы и ioctls. из ТТМ. [23]

С 2006 года проект nouveau разрабатывал бесплатный программный драйвер DRM для графических процессоров NVIDIA вне официального ядра Linux. В 2010 году исходный код nouveau был включен в Linux 2.6.33 в качестве экспериментального драйвера. [58] [59] На момент слияния драйвер уже был преобразован в KMS, а в рамках GEM API он использовал TTM в качестве диспетчера памяти. [146]

Новый API KMS, включая API GEM, стал важной вехой в развитии DRM, но это не помешало усовершенствованию API в последующие годы. KMS получил поддержку переворачивания страниц в сочетании с асинхронными уведомлениями VBLANK в Linux 2.6.33 [147] [148] — только для драйвера i915, Radeon и Nouveau добавили ее позже, во время выпуска Linux 2.6.38. [149] В libdrm 2.4.17 был добавлен новый интерфейс переворачивания страниц. [150] В начале 2011 года, во время цикла выпуска Linux 2.6.39, в KMS API были добавлены так называемые немые буферы — аппаратно-независимый неускоренный способ обработки простых буферов, подходящих для использования в качестве фреймбуферов. [151] [152] Целью было снизить сложность таких приложений, как Plymouth , которым не нужно использовать специальные ускоренные операции, предоставляемые ioctl для конкретного драйвера. [153] Эта функция была реализована в libdrm начиная с версии 2.4.25. [154] Позже в том же году он также получил новый основной тип объектов, названный самолетами . Плоскости были разработаны для представления аппаратных наложений, поддерживаемых механизмом сканирования. [155] [156] Поддержка Plane была включена в Linux 3.3. [157] и libdrm 2.4.30. Еще одной концепцией, добавленной в API — в выпусках Linux 3.5 [158] и libdrm 2.4.36 [159] — были универсальные свойства объекта — метод добавления универсальных значений к любому объекту KMS. Свойства особенно полезны для установки особого поведения или функций для таких объектов, как CRTC и плоскости.

Раннее доказательство концепции обеспечения разгрузки графического процессора между драйверами DRM было разработано Дэйвом Эйрли в 2010 году. [7] [160] Поскольку Эйрли пытался имитировать технологию NVIDIA Optimus , он решил назвать ее «PRIME». [7] Эйрли возобновил свою работу над PRIME в конце 2011 года, но на основе нового механизма совместного использования буфера DMA-BUF , представленного в ядре Linux 3.3. [161] Базовая инфраструктура DMA-BUF PRIME была завершена в марте 2012 года [162] и объединена с версией Linux 3.4, [163] [164] [165] , а также с libdrm 2.4.34. [166] Позже, в выпуске Linux 3.5, несколько драйверов DRM реализовали поддержку PRIME, включая i915 для карт Intel, radeon для карт AMD и nouveau для карт NVIDIA. [167] [168]

В последние годы API DRM постепенно расширялся за счет новых и улучшенных функций. В 2013 году в рамках GSoC Дэвид Херрманн разработал функцию нескольких узлов рендеринга . [55] Его код был добавлен в ядро ​​Linux версии 3.12 в качестве экспериментальной функции [169] [170], поддерживаемой драйверами i915, [171] radeon [172] и nouveau [173] и включенной по умолчанию, начиная с Linux 3.17. [77] В 2014 году Мэтт Ропер (Intel) разработал концепцию универсальных плоскостей (или унифицированных плоскостей ), согласно которой фреймбуферы ( первичные плоскости ), наложения ( вторичные плоскости ) и курсоры ( курсорные плоскости ) рассматриваются как объекты одного типа с единый API. [174] Поддержка универсальных плоскостей обеспечивает более согласованный API DRM с меньшим количеством общих ioctls . [33] Чтобы поддерживать обратную совместимость API , эта функция предоставляется ядром DRM как дополнительная возможность, которую может предоставить драйвер DRM. Поддержка универсальной плоскости дебютировала в Linux 3.15 [175] и libdrm 2.4.55. [176] Некоторые драйверы, такие как Intel i915, [177] уже реализовали это.

Самым последним усовершенствованием DRM API является атомарный API настройки режима , который обеспечивает атомарность операций настройки режима и перелистывания страниц на устройстве DRM. Идея атомарного API для настройки режимов была впервые предложена в начале 2012 года. [178] Вилле Сюрьяля (Intel) взял на себя задачу разработки и реализации такого атомарного API. [179] Основываясь на своей работе, Роб Кларк ( Texas Instruments ) применил аналогичный подход, стремясь реализовать атомарное переворачивание страниц. [180] Позже в 2013 году обе предложенные функции были объединены в одну с использованием одного ioctl для обеих задач. [181] Поскольку это было требованием, этой функции пришлось дождаться объединения поддержки универсальных самолетов в середине 2014 года. [177] Во второй половине 2014 года атомарный код был значительно улучшен Дэниелом Веттером (Intel) и другими разработчиками DRM [182] : 18  , чтобы облегчить переход существующих драйверов KMS на новую атомарную структуру. [183] ​​Вся эта работа была наконец объединена в выпуски Linux 3.19 [184] и Linux 4.0 [185] [186] [187] и включена по умолчанию, начиная с Linux 4.2. [188] Начиная с версии 2.4.62, libdrm предоставляет новый атомарный API. [189] Несколько драйверов уже преобразованы в новый атомарный API. [190] К 2018 году в ядро ​​Linux было добавлено десять новых драйверов DRM, основанных на этой новой атомарной модели. [191]

Принятие

Подсистема ядра Direct Rendering Manager изначально была разработана для использования с новой инфраструктурой Direct Rendering сервера отображения XFree86 4.0, позже унаследованной его преемником, сервером X.Org . Таким образом, основными пользователями DRM были клиенты DRI, которые ссылаются на реализацию OpenGL с аппаратным ускорением , находящуюся в библиотеке Mesa 3D , а также на самом X-сервере. В настоящее время DRM также используется несколькими наборщиками Wayland , включая эталонный наборщик Weston . kmscon — это реализация виртуальной консоли, которая работает в пользовательском пространстве с использованием средств DRM KMS. [192]

В 2015 году версия 358.09 (бета) проприетарного драйвера Nvidia GeForce получила поддержку интерфейса настройки режима DRM, реализованного в виде нового объекта ядра под названием nvidia-modeset.ko. Этот новый компонент драйвера работает вместе с nvidia.koмодулем ядра для программирования механизма отображения (т. е. контроллера дисплея) графического процессора. [193]

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

Рекомендации

  1. ^ "Ядро/драйверы Linux/gpu/drm/README.drm". ядро.орг . Архивировано из оригинала 26 февраля 2014 г. Проверено 26 февраля 2014 г.
  2. ^ аб Уиттерхувен, Герт. «Устройство кадрового буфера». Кернел.орг . Проверено 28 января 2015 г.
  3. ^ abc Уайт, Томас. «Как работают DRI и DRM» . Проверено 22 июля 2014 г.
  4. ↑ Вера, Рикард Э. (11 мая 1999 г.). «Диспетчер прямого рендеринга: поддержка ядра для инфраструктуры прямого рендеринга» . Проверено 12 мая 2016 г.
  5. ^ abcdefgh Корбет, Джонатан (6 ноября 2007 г.). «Управление памятью графических процессоров». LWN.net . Проверено 23 июля 2014 г. .
  6. ^ abcdefg Паккард, Кейт; Анхольт, Эрик (13 мая 2008 г.). «GEM — Менеджер графического выполнения». список рассылки dri-devel . Проверено 23 июля 2014 г. .
  7. ^ abc Airlie, Дэйв (12 марта 2010 г.). «Разгрузка графического процессора - ПРАЙМ - доказательство концепции». Архивировано из оригинала 10 февраля 2015 года . Проверено 10 февраля 2015 г.
  8. ^ abcde Китчинг, Саймон. «Модули ядра DRM и KMS» . Проверено 13 мая 2016 г.
  9. ^ abcde Herrmann, Дэвид (1 сентября 2013 г.). «Разделение узлов устройств DRM и KMS» . Проверено 23 июля 2014 г. .
  10. ^ "README.rst - mesa/drm - заголовки и модули ядра Direct Rendering Manager" . 21 марта 2020 г. Архивировано из оригинала 21 марта 2020 г.
  11. ^ ab Airlie, Дэйв (4 сентября 2004 г.). «Новый предлагаемый дизайн интерфейса DRM». dri-devel (список рассылки).
  12. ^ abcdefg Перес, Мартин; Равье, Тимоти (2 февраля 2013 г.). «DRI-next/DRM2: обзор графического стека Linux и его безопасности» (PDF) . Проверено 13 мая 2016 г.
  13. ↑ Хогсберг, Кристиан (4 сентября 2008 г.). «Расширение DRI2 — версия 2.0». X.Орг . Проверено 23 мая 2016 г.
  14. ^ abcdef Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Вуннер, Лукас. «Руководство разработчика драйверов графического процессора Linux — Управление памятью» . Проверено 31 августа 2016 г.
  15. ^ Веттер, Дэниел. «Ускоренный курс i915/GEM Дэниела Веттера». Центр технологий открытого исходного кода Intel . Проверено 31 января 2015 г. GEM по существу имеет дело с объектами графического буфера (которые могут содержать текстуры, буферы рендеринга, шейдеры или все виды других объектов состояния и данных, используемых графическим процессором).
  16. ↑ abc Vetter, Дэниел (4 мая 2011 г.). «Обзор GEM» . Проверено 13 февраля 2015 г.
  17. ↑ Паккард, Кейт (28 сентября 2012 г.). «Мысли о ДРИ.Next» . Проверено 26 мая 2016 г. У GEM flink много проблем. Имена flink являются глобальными, что позволяет любому, у кого есть доступ к устройству, получить доступ к содержимому данных flink.
  18. ^ Аб Херрманн, Дэвид (2 июля 2013 г.). «DRM Безопасность». Материалы конференции разработчиков X.Org 2013 (XDC2013) . Проверено 13 февраля 2015 г. gem-flink не предоставляет никаких частных пространств имен приложениям и серверам. Вместо этого для каждого узла DRM предоставляется только одно глобальное пространство имен. Вредоносные приложения, прошедшие проверку подлинности, могут атаковать других клиентов с помощью грубого перебора имен буферов драгоценных камней.
  19. ↑ Керриск, Майкл (25 сентября 2012 г.). «XDC2012: Безопасность графического стека». LWN.net . Проверено 25 ноября 2015 г.
  20. ↑ Ab Packard, Кейт (4 июля 2008 г.). «обновление драгоценных камней» . Проверено 25 апреля 2016 г.
  21. ^ "Справочная страница drm-memory" . Руководства по Ubuntu . Проверено 29 января 2015 г. Многие современные высокопроизводительные графические процессоры оснащены собственными диспетчерами памяти. Они даже включают в себя несколько разных кэшей, которые необходимо синхронизировать во время доступа. [...]. Таким образом, управление памятью на графических процессорах сильно зависит от драйверов и оборудования.
  22. ^ «Руководство разработчика Intel Graphics Media Accelerator» . Корпорация Интел . Проверено 24 ноября 2015 г.
  23. ↑ abc Ларабель, Майкл (26 августа 2008 г.). «Менеджер TTM для Radeon, модифицированный GEM». Фороникс . Проверено 24 апреля 2016 г.
  24. ^ abc Корбет, Джонатан (28 мая 2008 г.). «GEM против ТТМ». LWN.net . Проверено 10 февраля 2015 г.
  25. ↑ Корбет, Джонатан (11 января 2012 г.). «Совместное использование буфера DMA в версии 3.3». LWN.net . Проверено 14 мая 2016 г. .
  26. ^ Кларк, Роб; Семвал, Сумит. «Среда совместного использования буфера DMA: введение» (PDF) . Проверено 14 мая 2016 г. .
  27. ↑ Перес, Мартин (26 сентября 2014 г.). «Графический стек Linux, Optimus и драйвер Nouveau» (PDF) . Проверено 14 мая 2016 г. .
  28. ↑ Пинчарт, Лоран (20 февраля 2013 г.). «Анатомия встроенного драйвера KMS» (PDF) . Проверено 27 июня 2016 г.
  29. ↑ Эдж, Джейк (9 октября 2013 г.). «ДРИ3 и настоящее время». LWN.net . Проверено 28 мая 2016 г.
  30. ^ abcd «Linux 2.6.29 — Настройка режима ядра». Ядро Linux для новичков . Проверено 19 ноября 2015 г.
  31. ^ «Оборудование VGA». OSDev.org . Проверено 23 ноября 2015 г.
  32. ^ Ратманн, Б. (15 февраля 2008 г.). «Государство Нуво, часть I». LWN.net . Проверено 23 ноября 2015 г. Видеокарты программируются разными способами, но большая часть инициализации и настройки режима выполняется через отображенный в памяти ввод-вывод. Это всего лишь набор регистров, доступных ЦП через его стандартное адресное пространство памяти. Регистры в этом адресном пространстве разделены на диапазоны, относящиеся к различным функциям видеокарты, таким как настройка режима, управление выходом или конфигурация часов.
  33. ^ abcde Пааланен, Пекка (5 июня 2014 г.). «От предыстории до конца глобальной термоядерной войны» . Проверено 29 июля 2014 г.
  34. ^ "Справочная страница drm-kms" . Руководства по Ubuntu . Проверено 19 ноября 2015 г.
  35. ↑ Корбет, Джонатан (13 января 2010 г.). «Конец настройки режима пользовательского пространства?». LWN.net . Проверено 20 ноября 2015 г.
  36. ^ ab «Обсуждение дизайна настройки режима». X.Org Wiki . Проверено 19 ноября 2015 г.
  37. ^ аб Корбет, Джонатан (22 января 2007 г.). «LCA: Обновления системы X Window». LWN.net . Проверено 23 ноября 2015 г.
  38. ^ "Страница руководства XF86VIDMODE" . X.Орг . Проверено 23 апреля 2016 г.
  39. ^ «Примечания к выпуску X11R6.1» . X.Орг . 14 марта 1996 года . Проверено 23 апреля 2016 г.
  40. ↑ Корбет, Джонатан (20 июля 2004 г.). «Саммит ядра: видеодрайверы». LWN.net . Проверено 23 ноября 2015 г.
  41. ^ ab «Fedora — Функции/KernelModeSetting». Проект Федора . Проверено 20 ноября 2015 г. Исторически сложилось так, что X-сервер отвечал за сохранение состояния вывода при запуске, а затем за его восстановление при переключении обратно в текстовый режим. Быстрое переключение пользователей осуществлялось с помощью переключателя VT, поэтому при выходе из X-сервера первого пользователя мигало один раз, чтобы перейти в текстовый режим, а затем сразу же мигало снова, чтобы перейти к сеансу второго пользователя.
  42. ^ abcde Барнс, Джесси (17 мая 2007 г.). «[RFC] улучшение графической подсистемы ядра». linux-kernel (список рассылки).
  43. ^ abc «DrmModesetting — Улучшение графики ядра». ДРИ Вики . Проверено 23 ноября 2015 г.
  44. ^ abcde Packard, Кейт (16 сентября 2007 г.). "драйверы режима ядра" . Проверено 30 апреля 2016 г.
  45. ^ аб Паккард, Кейт (24 апреля 2000 г.). «Усиление внимания драйверов Intel» . Проверено 23 мая 2016 г. Более тонкое ограничение заключается в том, что драйвер не мог обрабатывать прерывания, поэтому не было поддержки монитора с возможностью горячего подключения.
  46. ^ Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Вуннер, Лукас. «Руководство разработчика драйверов графического процессора Linux — Инициализация драйвера» . Проверено 31 августа 2016 г.
  47. ^ "q3k (@[email protected])" . Варшавский социальный клуб Hackerspace . 31 января 2023 г. Проверено 13 февраля 2023 г. Драйвер DRM/KMS теперь полностью работает, хотя все еще без DMA. Да, и он написан на Rust, хотя по большей части он просто полон сырых небезопасных блоков.
  48. ^ "q3k (@[email protected])" . Варшавский социальный клуб Hackerspace . 31 января 2023 г. Проверено 13 февраля 2023 г. Круто то, что, поскольку у нас есть «обычный» драйвер DRM/KMS (и помощь от @[email protected]), мы можем просто делать такие вещи, как... запускать Wayland! Уэстон на iPod Nano 5G.
  49. ^ abcdefg Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Вуннер, Лукас. «Руководство разработчика драйверов графического процессора Linux — Инициализация и очистка KMS» . Проверено 31 августа 2016 г.
  50. ^ ab «Видеокарты». X.Org Wiki . Проверено 11 апреля 2016 г.
  51. ^ аб Дойчер, Алекс (15 апреля 2010 г.). «Заметки об аппаратном обеспечении дисплея Radeon». Архивировано из оригинала 5 апреля 2016 года . Проверено 8 апреля 2016 г.
  52. ^ abcde Vetter, Дэниел (5 августа 2015 г.). «Обзор конструкции настройки атомарного режима, часть 1». LWN.net . Проверено 7 мая 2016 г.
  53. ^ аб Рединг, Тьерри (1 февраля 2015 г.). «Атомная настройка режима» (PDF) . Архив ФОСДЕМ . Проверено 7 мая 2016 г.
  54. ↑ Веттер, Дэниел (12 августа 2015 г.). «Обзор конструкции настройки атомарного режима, часть 2». LWN.net . Проверено 7 мая 2016 г.
  55. ^ abc Херрманн, Дэвид (29 мая 2013 г.). «Узлы рендеринга и модсета DRM» . Проверено 21 июля 2014 г.
  56. ^ abcd Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Вуннер, Лукас. «Руководство разработчика драйверов графического процессора Linux — узлы рендеринга» . Проверено 31 августа 2016 г.
  57. ^ Аб Дойчер, Алекс (20 апреля 2015 г.). «Первоначальная версия драйвера amdgpu». dri-devel (список рассылки).
  58. ^ ab «Linux 2.6.33 — Nouveau, драйвер для графических карт Nvidia». Ядро Linux для новичков . Проверено 26 апреля 2016 г.
  59. ^ ab «drm/nouveau: добавьте драйвер DRM для графических процессоров NVIDIA». Кернел.орг . Проверено 27 января 2015 г.
  60. ^ «DRM: добавьте драйвер DRM для Samsung SoC EXYNOS4210» . Кернел.орг . Проверено 3 марта 2016 г.
  61. ^ «vmwgfx: вывести драйвер из промежуточного режима» . Кернел.орг . Проверено 3 марта 2016 г.
  62. ^ «Linux 3.3 — DriverArch — Графика» . Ядро Linux для новичков . Проверено 3 марта 2016 г.
  63. ↑ Ларабель, Майкл (10 января 2012 г.). «В Linux 3.3 DRM много улучшений». Фороникс . Проверено 3 марта 2016 г.
  64. ^ «drm: Начальный драйвер KMS для серии AST (ASpeed ​​Technologies) 2000 (v2)» . Кернел.орг . Проверено 3 марта 2016 г.
  65. ↑ Эйрли, Дэйв (17 мая 2012 г.). «mgag200: начальный драйвер g200se (v2)» . Проверено 24 января 2018 г.
  66. ^ «drm: Драйвер Renesas SH Mobile DRM» . Кернел.орг . Проверено 3 марта 2016 г.
  67. ^ «drm: добавить поддержку NVIDIA Tegra20» . Кернел.орг . Проверено 3 марта 2016 г.
  68. ^ «drm/omap: выйти из стадии подготовки». Кернел.орг . Проверено 3 марта 2016 г.
  69. ^ "drm: Драйвер DRM Renesas R-Car Display Unit" . Кернел.орг . Проверено 3 марта 2016 г.
  70. ^ «drm/msm: базовый драйвер KMS для львиного зева» . Кернел.орг . Проверено 3 марта 2016 г.
  71. ↑ Ларабель, Майкл (28 августа 2013 г.). «Драйвер Snapdragon DRM/KMS объединен для Linux 3.12». Фороникс . Проверено 26 января 2015 г.
  72. ↑ Эдж, Джейк (8 апреля 2015 г.). «Обновление графического драйвера freedreno». LWN.net . Проверено 23 апреля 2015 г.
  73. ↑ Кинг, Рассел (18 октября 2013 г.). «[GIT PULL] Поддержка Armada DRM». dri-devel (список рассылки).
  74. ^ «DRM: Армада: Добавьте драйвер DRM Armada» . Кернел.орг . Проверено 3 марта 2016 г.
  75. ^ "drm/bochs: новый драйвер" . Кернел.орг . Проверено 3 марта 2016 г.
  76. ↑ Ларабель, Майкл (8 августа 2014 г.). «Linux 3.17 DRM Pull приносит новый графический драйвер» . Фороникс . Проверено 3 марта 2016 г.
  77. ^ аб Корбет, Джонатан (13 августа 2014 г.). «Окно слияния 3.17, часть 2». LWN.net . Проверено 7 октября 2014 г.
  78. ^ аб Корбет, Джонатан (17 декабря 2014 г.). «3.19 Объединить окно, часть 2». LWN.net . Проверено 9 февраля 2015 г.
  79. ^ «drm: imx: Переместить драйвер imx-drm из промежуточного состояния». Кернел.орг . Проверено 9 февраля 2015 г.
  80. ^ «drm: rockchip: добавить базовый драйвер drm» . Кернел.орг . Проверено 3 марта 2016 г.
  81. ↑ Ларабель, Майкл (25 июня 2015 г.). «Обновления DRM для Linux 4.2: много внимания со стороны AMD, никаких изменений в драйверах Nouveau». Фороникс . Проверено 31 августа 2015 г.
  82. ↑ Корбет, Джонатан (1 июля 2015 г.). «4.2 Объединить окно, часть 2». LWN.net . Проверено 31 августа 2015 г.
  83. ↑ Дойчер, Алекс (3 августа 2015 г.). «[ОБНОВЛЕНИЕ 00/11] Добавлена ​​поддержка Фиджи». dri-devel (список рассылки).
  84. ^ «Добавить драйвер видеокарты Virtio» . Кернел.орг . Проверено 3 марта 2016 г.
  85. ↑ Корбет, Джонатан (11 ноября 2015 г.). «4.4 Окно слияния, часть 1». LWN.net . Проверено 11 января 2016 г.
  86. ↑ Ларабель, Майкл (15 ноября 2015 г.). «Взгляд на новые возможности ядра Linux 4.4». Фороникс . Проверено 11 января 2016 г.
  87. ^ «drm/vc4: добавить поддержку KMS для Raspberry Pi» . Кернел.орг .
  88. ^ «Linux 4.5-DriversArch — Графика» . Ядро Linux для новичков . Проверено 14 марта 2016 г.
  89. ↑ Ларабель, Майкл (24 января 2016 г.). «Множество новых функций и улучшений ядра Linux 4.5». Фороникс . Проверено 14 марта 2016 г.
  90. ↑ Корбет, Джонатан (20 января 2016 г.). «Окно слияния 4.5, часть 2». LWN.Net . Проверено 14 марта 2016 г.
  91. ^ «Объединить тег 'sun4i-drm-for-4.7'» . Кернел.орг .
  92. ↑ abc Airlie, Дэйв (23 мая 2016 г.). «[git pull] drm для версии 4.7». dri-devel (список рассылки).
  93. ^ «Объединить тег 'drm-hisilicon-next-2016-04-29'» . Кернел.орг .
  94. ^ «Объединить тег 'mediatek-drm-2016-05-09'» . Кернел.орг .
  95. ↑ Ларабель, Майкл (22 ноября 2016 г.). «Драйвер Hisilicon Hibmc DRM добавляется для Linux 4.10» . Фороникс . Проверено 24 января 2018 г.
  96. ^ «Технический документ Huawei FusionServer RH5885 V3» . 18 ноября 2016 г. Архивировано из оригинала 25 января 2018 г. использует встроенный чип дисплея, интегрированный в микросхему управления Hi1710 и использующий IP-ядро SM750.
  97. ^ «drm/vkms: введение базового драйвера VKMS» . git.kernel.org . Проверено 20 июля 2022 г.
  98. ↑ Ларабель, Майкл (15 августа 2018 г.). «В Linux 4.19 добавляется драйвер настройки режима виртуального ядра». Фороникс . Проверено 20 июля 2022 г.
  99. ^ «kernel/git/torvalds/linux.git — дерево исходного кода ядра Linux». git.kernel.org . Проверено 28 ноября 2019 г.
  100. ^ abc Ларабель, Майкл (9 мая 2019 г.). «Linux 5.2 DRM готов к работе с Icelake, добавлены драйверы Lima и Panfrost». Фороникс . Проверено 20 июля 2022 г.
  101. ^ «kernel/git/torvalds/linux.git — дерево исходного кода ядра Linux». git.kernel.org . Проверено 28 ноября 2019 г.
  102. ^ «drm/vboxvideo: переместите драйвер vboxvideo из промежуточного режима» . git.kernel.org . Проверено 20 июля 2022 г.
  103. ^ «drm/hyperv: добавить драйвер DRM для синтетического видеоустройства Hyperv» . git.kernel.org . Проверено 30 августа 2021 г.
  104. ↑ Ларабель, Майкл (9 июня 2021 г.). «Драйвер дисплея Microsoft Hyper-V DRM появится для Linux 5.14» . Фороникс . Проверено 30 августа 2021 г.
  105. ^ «drm: Добавить драйвер simpledrm» . git.kernel.org . Проверено 30 августа 2021 г.
  106. ↑ Ларабель, Майкл (13 мая 2021 г.). «Linux 5.14 включает драйвер SimpleDRM, VC4 HDR, помечает больше кода AGP как устаревший» . Фороникс . Проверено 30 августа 2021 г.
  107. ^ «drm/ofdrm: добавлено ofdrm для кадровых буферов открытой прошивки» . git.kernel.org . Проверено 21 февраля 2023 г.
  108. ↑ Ларабель, Майкл (20 октября 2022 г.). «Открыть встроенный драйвер DRM «OFDRM» в очереди для Linux 6.2». Фороникс . Проверено 21 февраля 2023 г.
  109. ^ «drm: добавить драйвер kms для контроллера дисплея loongson» . git.kernel.org . Проверено 23 февраля 2024 г.
  110. ↑ Ларабель, Майкл (13 июля 2023 г.). «Обновления графических драйверов с открытым исходным кодом начинают стоять в очереди для Linux 6.6» . Фороникс . Проверено 23 февраля 2024 г.
  111. ^ «drm: удалить гамма-драйвер» . Кернел.орг . Проверено 27 января 2015 г.
  112. ^ «[DRM]: удалить код драйвера sparc64 FFB, который так и не был построен» . Кернел.орг . Проверено 27 января 2015 г.
  113. ^ «drm: удалите устаревший драйвер-tdfx». Кернел.орг . Проверено 23 февраля 2024 г.
  114. ^ «drm: удалите устаревший драйвер-mga» . Кернел.орг . Проверено 23 февраля 2024 г.
  115. ^ «drm: удалите устаревший драйвер-r128» . Кернел.орг . Проверено 23 февраля 2024 г.
  116. ^ «drm: удалите устаревший драйвер-i810» . Кернел.орг . Проверено 23 февраля 2024 г.
  117. ^ «drm: Удалить устаревший драйвер-sis» . Кернел.орг . Проверено 23 февраля 2024 г.
  118. ^ «drm: удалить драйвер i830» . Кернел.орг . Проверено 27 января 2015 г.
  119. ^ «drm: Добавить через поддержку unichrome» . Кернел.орг . Проверено 27 января 2015 г.
  120. ^ «drm: удалите устаревший драйвер». Кернел.орг . Проверено 23 февраля 2024 г.
  121. ^ «drm: добавить дикого драйвера» . Кернел.орг . Проверено 27 января 2015 г.
  122. ^ «drm: Удалить устаревший драйвер-дикарь» . Кернел.орг . Проверено 23 февраля 2024 г.
  123. ^ «Список сопровождающих ядра Linux» . Кернел.орг . Проверено 14 июля 2014 г.
  124. ^ "репозиторий libdrm git" . Проверено 23 июля 2014 г. .
  125. ^ «Первая версия DRI драйвера 3dfx» . Меса 3D . Проверено 15 июля 2014 г.
  126. ^ «Импортировать 2.3.18pre1». История Linux в формате репозитория GIT 1992–2010 (2010) . Проверено 15 июля 2014 г.
  127. ^ Торвальдс, Линус. «Исходный код Linux 2.4.0». Кернел.орг . Проверено 29 июля 2014 г.
  128. ↑ Эйрли, Дэйв (30 декабря 2004 г.). «[bk pull] ядро/раскол личности». linux-kernel (список рассылки).
  129. ↑ Торвальдс, Линус (11 января 2005 г.). «Линукс 2.6.11-rc1». linux-kernel (список рассылки).
  130. ^ Геттис, Джеймс; Паккард, Кейт (15 июня 2004 г.). «(Ре)Архитектура системы X Window» . Проверено 30 апреля 2016 г.
  131. ↑ Смирл, Джон (30 августа 2005 г.). «Состояние графики Linux» . Проверено 30 апреля 2016 г. Я считаю, что лучшим решением этой проблемы будет предоставление ядром единого комплексного драйвера устройства для каждой части видеооборудования. Это означает, что конфликтующие драйверы, такие как fbdev и DRM, должны быть объединены в сотрудничающую систему. Это также означает, что следует запретить использование оборудования из пользовательского пространства во время загрузки драйвера устройства на основе ядра.
  132. ↑ Верхаген, Люк (2 марта 2006 г.). «X и настройка режима: иллюстрация атрофии» (PDF) . Проверено 30 апреля 2016 г.
  133. ^ Глисс, Джером (4 декабря 2007 г.). «Настройка режима ядра Radeon» . Проверено 30 апреля 2016 г.
  134. ^ Ларабель, Майкл (1 октября 2008 г.). «Состояние настройки режима ядра». Фороникс . Проверено 30 апреля 2016 г.
  135. ↑ Паккард, Кейт (21 июля 2008 г.). «Статус выхода X июль 2008 г.» . Проверено 1 мая 2016 г.
  136. ^ «drm: реорганизовать дерево drm, чтобы оно было более перспективным» . Кернел.орг .
  137. ^ «Linux 2.6.28 — Диспетчер памяти GEM для памяти графического процессора» . Ядро Linux для новичков . Проверено 23 июля 2014 г. .
  138. ^ «drm: добавьте подсистему диспетчера памяти графического процессора TTM» . Кернел.орг .
  139. ^ «DRM: добавить поддержку настройки режима» . Кернел.орг .
  140. ^ «DRM: i915: добавить поддержку настройки режима» . Кернел.орг .
  141. ↑ Анхольт, Эрик (22 декабря 2008 г.). «[ОБЪЯВЛЕНИЕ] libdrm-2.4.3». dri-devel (список рассылки).
  142. ↑ Барнс, Джесси (20 октября 2008 г.). «[АНОНС] xf86-video-intel 2.5.0». xorg-announce (список рассылки).
  143. ^ «Linux 2.6.31 — поддержка настройки режима ядра ATI Radeon» . Ядро Linux для новичков . Архивировано из оригинала 5 ноября 2015 года . Проверено 28 апреля 2016 г.
  144. ↑ Торвальдс, Линус (9 сентября 2009 г.). «Линукс 2.6.31». linux-kernel (список рассылки).
  145. ^ «drm/radeon: введение настройки режима ядра для оборудования Radeon» . Кернел.орг .
  146. ^ "Необычный спутник развития Nouveau # 40" . Проект «Нуво» . Проверено 3 мая 2016 г.
  147. ^ «Linux 2.6.33 — Улучшения графики» . Ядро Linux для новичков . Проверено 28 апреля 2016 г.
  148. ^ «drm/kms: добавить перелистывание страниц ioctl» . Кернел.орг .
  149. ^ «Linux 2.6.38 — Графика» . Ядро Linux для новичков . Проверено 28 апреля 2016 г.
  150. ↑ Эйрли, Дэйв (21 декабря 2009 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.17». dri-devel (список рассылки).
  151. ^ «drm: тупое сканирование create/mmap для Intel/radeon (v3)» . Кернел.орг .
  152. ^ "Linux 2 6 39-DriversArch" . Ядро Linux для новичков . Проверено 19 апреля 2016 г.
  153. ^ Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Вуннер, Лукас. «Руководство разработчика драйверов графического процессора Linux — Тупые объекты буфера» . Проверено 31 августа 2016 г.
  154. ↑ Уилсон, Крис (11 апреля 2011 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.25». dri-devel (список рассылки).
  155. ↑ Барнс, Джесси (25 апреля 2011 г.). «[RFC] drm: добавление наложений в качестве объектов KMS первого класса». dri-devel (список рассылки).
  156. ↑ Барнс, Джесси (13 мая 2011 г.). «[RFC] drm: добавление наложений в качестве объектов KMS первого класса». dri-devel (список рассылки).
  157. ^ «drm: добавить поддержку самолетов v3» . Кернел.орг .
  158. ^ «drm: добавьте общие ioctls для получения/установки свойств любого объекта». Кернел.орг .
  159. ^ Видавски, Бен (27 июня 2012 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.36». xorg-announce (список рассылки).
  160. ^ Ларабель, Майкл. «Подтверждение концепции: рендеринг с использованием нескольких графических процессоров с открытым исходным кодом!». Фороникс . Проверено 14 апреля 2016 г.
  161. ↑ Ларабель, Майкл (23 февраля 2012 г.). «База DRM PRIME поддерживает часть работы VGEM» . Фороникс . Проверено 14 апреля 2016 г.
  162. ↑ Эйрли, Дэйв (27 марта 2012 г.). «[ИСПРАВЛЕНИЕ] drm: базовая поддержка prime/dma-buf (v5)». dri-devel (список рассылки).
  163. ↑ Ларабель, Майкл (30 марта 2012 г.). «Горящая минута для Linux 3.4: поддержка DMA-BUF PRIME». Фороникс . Проверено 15 апреля 2016 г.
  164. ^ «drm: базовая поддержка prime/dma-buf (v5)» . Кернел.орг .
  165. ^ "Linux 3.4 DriverArch" . Ядро Linux для новичков . Проверено 15 апреля 2016 г.
  166. ↑ Анхольт, Эрик (10 мая 2012 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.34». dri-devel (список рассылки).
  167. ↑ Ларабель, Майкл (12 мая 2012 г.). «DMA-BUF PRIME собирается вместе для Linux 3.5». Фороникс . Проверено 15 апреля 2016 г.
  168. ^ "Linux 3.5 DriverArch" . Ядро Linux для новичков . Проверено 15 апреля 2016 г.
  169. ↑ Корбет, Джонатан (11 сентября 2013 г.). «Окно слияния 3.12, часть 2». LWN.net . Проверено 21 июля 2014 г.
  170. ^ «drm: реализовать экспериментальные узлы рендеринга» . Кернел.орг .
  171. ^ «drm/i915: Поддержка узлов рендеринга» . Кернел.орг .
  172. ^ «drm/radeon: поддержка узлов рендеринга» . Кернел.орг .
  173. ^ «drm/nouveau: Поддержка узлов рендеринга» . Кернел.орг .
  174. ↑ Ропер, Мэтт (7 марта 2014 г.). «[RFCv2 00/10] Поддержка универсальной плоскости». dri-devel (список рассылки).
  175. ↑ Ларабель, Майкл (2 апреля 2014 г.). «Универсальный набор опор для самолетов для Linux 3.15». Фороникс . Проверено 14 апреля 2016 г.
  176. ↑ Ланкхорст, Мартен (25 июля 2014 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.55». dri-devel (список рассылки).
  177. ↑ Аб Веттер, Дэниел (7 августа 2014 г.). «Отличная штука для 3.17» . Проверено 14 апреля 2016 г.
  178. ↑ Барнс, Джесси (15 февраля 2012 г.). «[RFC] drm: API установки атомарного режима». dri-devel (список рассылки).
  179. ↑ Сюрьяля, Вилле (24 мая 2012 г.). «[RFC][PATCH 0/6] WIP: drm: Идея настройки атомарного режима». dri-devel (список рассылки).
  180. ↑ Кларк, Роб (9 сентября 2012 г.). «[RFC 0/9] ядерный переворот страницы» . dri-devel (список рассылки).
  181. ↑ Кларк, Роб (6 октября 2013 г.). «[RFCv1 00/12] Атомный/ядерный набор режимов/переворот страницы». dri-devel (список рассылки).
  182. ↑ Веттер, Дэниел (3 февраля 2016 г.). «Примите эпоху атомного дисплея» (PDF) . Проверено 4 мая 2016 г.
  183. ↑ Веттер, Дэниел (2 ноября 2014 г.). «Поддержка атомарного режима набора драйверов KMS» . Проверено 4 мая 2016 г.
  184. ↑ Эйрли, Дэйв (14 декабря 2014 г.). «[git pull] drm для 3.19-rc1». dri-devel (список рассылки).
  185. ↑ Веттер, Дэниел (28 января 2015 г.). «Обновление для обновлений Atomic Display» . Проверено 4 мая 2016 г.
  186. ↑ Эйрли, Дэйв (15 февраля 2015 г.). «[git pull] drm pull для 3.20-rc1». dri-devel (список рассылки).
  187. ^ «Linux 4.0 — DriverArch — Графика» . Ядро Linux для новичков . Проверено 3 мая 2016 г.
  188. ^ «Linux 4.2 — API атомарной настройки мод включен по умолчанию» . Ядро Linux для новичков . Проверено 3 мая 2016 г.
  189. ↑ Великов, Эмиль (29 июня 2015 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.62». dri-devel (список рассылки).
  190. ↑ Веттер, Дэниел (6 июня 2016 г.). «Удивительные атомные достижения» . Проверено 7 июня 2016 г. сейчас 17 драйверов, поддерживающих атомарную настройку мод, объединены в подсистему DRM
  191. ↑ Стоун, Дэниел (20 марта 2018 г.). «Новая эра низкоуровневой графики Linux. Часть 1» . Проверено 5 мая 2018 г.
  192. ↑ Херрманн, Дэвид (10 декабря 2012 г.). «Введение в KMSCON» . Проверено 22 ноября 2015 г.
  193. ^ «Драйвер Linux, Solaris и FreeBSD 358.09 (бета)» . 10 декабря 2015 г.

Внешние ссылки