✖


Jump to content

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

(Перенаправлено из настройки атомного режима )
Не путать с управлением цифровыми правами .
Оригинальный автор(ы) kernel.org и freedesktop.org
Разработчик(и) kernel.org и freedesktop.org
Написано в С
Тип
Лицензия
Веб-сайт дри .freedesktop .org /неделя /DRM

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

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

Обзор

[ редактировать ]

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

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

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

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

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

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

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

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

Библиотека под названием 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 . Только один из всех процессов, имеющих узел устройства. /dev/dri/cardX будет иметь дескриптор файла, помеченный как главный, в частности, первый вызов SET_MASTER ioctl. Любая попытка использовать один из этих ограниченных ioctl, не являясь DRM-Master, вернет ошибку. Процесс также может отказаться от своей главной роли и позволить другому процессу получить ее, вызвав DROP_MASTER ioctl.

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

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

  • Клиент получает уникальный токен — 32-битное целое число — от устройства DRM, используя GET_MAGIC ioctl и передает его процессу DRM-Master любым способом (обычно это какой-то IPC ; например, в DRI2 есть Запрос DRI2Authenticate , который любой X-клиент может отправить на X-сервер. [ 13 ] )
  • Процесс DRM-Master, в свою очередь, отправляет токен обратно на устройство DRM, вызывая AUTH_MAGIC ioctl.
  • Устройство предоставляет специальные права дескриптору файла процесса, чей токен аутентификации соответствует токену, полученному от DRM-Master.

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

[ редактировать ]

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

GEM предоставляет API с явными примитивами управления памятью . [ 6 ] С помощью GEM программа пользовательского пространства может создавать, обрабатывать и уничтожать объекты памяти, находящиеся в видеопамяти графического процессора. Эти объекты, называемые «объектами GEM», [ 14 ] являются постоянными с точки зрения программы пользовательского пространства и не требуют перезагрузки каждый раз, когда программа восстанавливает контроль над графическим процессором. Когда программе пользовательского пространства требуется фрагмент видеопамяти (для хранения кадрового буфера , текстуры или любых других данных, требуемых графическим процессором). [ 15 ] ), он запрашивает выделение драйвера DRM с помощью API GEM. Драйвер 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) — это ядра Linux, внутренний API разработанный для предоставления общего механизма для совместного использования буферов 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 — обрабатывал случай, когда пользователь переключался из графической среды на текстовую виртуальную консоль , сохраняя состояние настройки режима и восстанавливая его при переключении пользователя. вернемся к Х. [ 41 ] Этот процесс вызывал раздражающее мерцание при переходе, а также может привести к сбою, что приведет к повреждению или непригодности вывода на экран. [ 42 ]

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

  • Процесс приостановки/возобновления должен полагаться на инструменты пользовательского пространства для восстановления предыдущего режима. Один-единственный сбой или сбой одной из этих программ может привести к тому, что система останется без рабочего дисплея из-за неправильной конфигурации модема и, следовательно, станет непригодной для использования.
  • Ядро также не могло отображать сообщения об ошибках или отладке, когда экран находился в графическом режиме — например, когда X работал — поскольку единственными режимами, о которых знало ядро, были стандартные текстовые режимы VESA BIOS.
  • Более насущной проблемой было распространение графических приложений в обход X-сервера и появление других альтернатив X графическому стеку, что еще больше увеличивало дублирование кода установки режима в системе.

Чтобы решить эти проблемы, код установки режима был перенесен в одно место внутри ядра, а именно в существующий модуль 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 ]

  • CRTC : каждый CRTC (из CRT контроллера [ 50 ] [ 33 ] ) представляет механизм сканирования контроллера дисплея, указывающий на буфер сканирования ( framebuffer ). [ 49 ] Целью CRTC является чтение данных пикселей, находящихся в данный момент в буфере сканирования, и генерирование из них сигнала синхронизации видеорежима с помощью схемы ФАПЧ . [ 51 ] Количество доступных CRTC определяет, сколько независимых устройств вывода оборудование может обрабатывать одновременно, поэтому для использования конфигураций с несколькими головками требуется хотя бы один CRTC на каждое устройство отображения. [ 49 ] Два или более CRTC также могут работать в режиме клонирования , если они сканируют из одного и того же кадрового буфера для отправки одного и того же изображения на несколько устройств вывода. [ 51 ] [ 50 ]
  • Разъемы : разъем представляет собой место, куда контроллер дисплея отправляет видеосигнал в результате операции сканирования для отображения. Обычно концепция разъема KMS соответствует физическому разъему ( VGA , DVI , FPD-Link , HDMI , DisplayPort , S-Video ,...) в аппаратном обеспечении, где находится устройство вывода ( монитор , ноутбука панель ,... ) постоянно или может быть прикреплено временно. Информация, относящаяся к текущему физически подключенному устройству вывода, такая как состояние подключения, данные EDID , состояние DPMS или поддерживаемые режимы видео, также хранится в разъеме. [ 49 ]
  • Кодеры : контроллер дисплея должен кодировать сигнал синхронизации видеорежима от CRTC, используя формат, подходящий для предполагаемого разъема. [ 49 ] Кодер представляет собой аппаратный блок, способный выполнять одно из этих кодировок. Примерами кодировок для цифровых выходов являются TMDS и LVDS ; для аналоговых выходов, таких как VGA и TV-выход, ЦАП обычно используются специальные блоки . Разъем может одновременно принимать сигнал только от одного кодера. [ 49 ] и каждый тип разъема поддерживает только некоторые кодировки. Также могут существовать дополнительные физические ограничения, из-за которых не каждый CRTC подключается к каждому доступному кодировщику, что ограничивает возможные комбинации CRTC-кодировщик-разъем.
  • Плоскости : плоскость — это не аппаратный блок, а объект памяти, содержащий буфер, из которого питается механизм сканирования (CRTC). Плоскость, содержащая кадровый буфер, называется основной плоскостью , и с каждым CRTC должен быть связан один, [ 49 ] поскольку это источник для CRTC, определяющий режим видео — разрешение дисплея (ширина и высота), размер пикселей, формат пикселей, частота обновления и т. д. CRTC может также иметь связанные с ним плоскости курсора , если контроллер дисплея поддерживает аппаратные наложения курсора. или вторичные плоскости , если он способен сканировать из дополнительных аппаратных наложений и компоновать или смешивать «на лету» окончательное изображение, отправленное на устройство вывода. [ 33 ]

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

[ редактировать ]

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

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

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

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

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

DRM-драйверы
Водитель Поскольку ядро Поддерживаемое оборудование Поддержка поставщиков Статус/Примечания
радеон 2.4.1 Серия графических процессоров AMD (ранее ATi) Radeon с архитектурами TeraScale и GCN 1-го и 2-го поколения . модели R100 / 200 / 300 / 400 , X1000 , HD 2000/4000/5000/6000/7000/8000 и R9 R7 APU Kaveri . / 200/300 серий , ​ Radeon ​ / Включая R5 Да Активный
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. Да Активный
новый 2.6.33 [ 58 ] [ 59 ] NVIDIA Tesla , Fermi , Kepler , Maxwell на базе графические процессоры GeForce , Tegra K1 , X1 SoC Частичный Активный
эксинос 3.2 [ 60 ] SoC Samsung Exynos на базе ARM
vmwgfx 3.2 (из постановки) [ 61 ] Виртуальный графический процессор для VMware SVGA2 виртуальный водитель
гма500 3.3 (из постановки) [ 62 ] [ 63 ] Intel GMA 500 и других технологий Imagination ( PowerVR Графические процессоры на базе ) экспериментальный 2D-драйвер только для KMS
Аст 3.5 [ 64 ] Серия ASpeed ​​Technologies 2000 экспериментальный
мгаг200 3.5 [ 65 ] Matrox Серверные дисплеи MGA-G200 только для KMS
шмобиль 3.7 [ 66 ] Ренесас Ш Мобайл
тегра 3.8 [ 67 ] NVIDIA Tegra SoC 20, Tegra30 Да Активный
омапдрм 3.9 [ 68 ] Texas Instruments OMAP SoC 5
rcar-ты 3.11 [ 69 ] Renesas Дисплеи R-Car SoC
МСМ 3.12 [ 70 ] [ 71 ] Семейства графических процессоров Qualcomm Adreno SOC A2xx/A3xx/A4xx ( Snapdragon ) [ 72 ]
армада 3.13 [ 73 ] [ 74 ] Marvell Процессоры Armada 510
Бохс 3.14 [ 75 ] Виртуальные VGA, карты использующие интерфейс Bochs dispi vga (например, QEMU stdvga) виртуальный водитель
эти 3.17 [ 76 ] [ 77 ] STMicroelectronics SoC серии stiH41x
imx 3.19 (из постановки) [ 78 ] [ 79 ] Freescale i.MX SoC
рокчип 3.19 [ 78 ] [ 80 ] Rockchip Графические процессоры на базе SoC только для KMS
амдгпу [ 57 ] 4.2 [ 81 ] [ 82 ] Серия графических процессоров AMD Radeon с архитектурой GCN 3-го и 4-го поколения . Radeon Rx 200/300/400/500 ​ ​ . Включая модели [ 83 ] серии и APU Carrizo и Bristol & Stoney Ridge . Да Активный
виртио 4.2 [ 84 ] Драйвер виртуального графического процессора для QEMU менеджеров виртуальных машин на базе (например, KVM или Xen ). виртуальный водитель
vc4 4.4 [ 85 ] [ 86 ] [ 87 ] Raspberry Pi BCM2835 и BCM2836 от SoC Broadcom ( графический процессор VideoCore IV)
Этнавив 4.5 [ 88 ] [ 89 ] [ 90 ] Ядра графического процессора Vivante присутствуют в нескольких SoC, таких как Marvell ARMADA и Freescale i.MX6 Series.
солнце4i 4.7 [ 91 ] [ 92 ] SoC Allwinner (графический процессор ARM Mali-400 )
сделать 4.7 [ 93 ] [ 92 ] HiSilicon Kirin hi6220 SoC (графический процессор ARM Mali 450-MP4 )
медиатек 4.7 [ 94 ] [ 92 ] MediaTek MT8173 SoC (графический процессор Imagination PowerVR GX6250)
HibMC 4.10 [ 95 ] HiSilicon hi1710 Huawei iBMC SoC ( Silicon Image SM750) ядро графического процессора [ 96 ] ) только для KMS
вкмс 4.19 [ 97 ] [ 98 ] Программная модель драйвера KMS, полезная для тестирования и запуска X (или аналогичного) на автономных компьютерах . виртуальный драйвер, экспериментальный
пять 5.2 [ 99 ] [ 100 ] Графические процессоры ARM Mali 4xx
панфрост 5.2 [ 101 ] [ 100 ] Графические процессоры ARM Mali Txxx (Midgard) и Gxx (Bifrost)
vboxvideo 5.2 (из постановки) [ 102 ] [ 100 ] Драйвер виртуального графического процессора для VirtualBox (VBoxVGA GPU) виртуальный водитель
гиперв_дрм 5.14 [ 103 ] [ 104 ] Драйвер виртуального графического процессора для Hyper-V синтетического видеоустройства виртуальный водитель
простойдрм 5.14 [ 105 ] [ 106 ] Драйвер графического процессора для кадровых буферов, предоставляемых микропрограммным обеспечением ( UEFI GOP , расширения VESA BIOS , встроенные системы )
ofdrm 6.2 [ 107 ] [ 108 ] Драйвер графического процессора для с открытой прошивкой кадровых буферов
Лунсон 6.6 [ 109 ] [ 110 ] Драйвер графического процессора для Loongson графических процессоров и SoC
мощностьвр 6.8 [ 111 ] [ 112 ] Imagination Technologies PowerVR ( серия 6 и новее) и графические процессоры IMG Graphics
машина 6.8 [ 113 ] [ 114 ] Intel Xe Графические процессоры серии (встроенные графические процессоры Gen12 , дискретные графические процессоры Intel Arc ) Да экспериментальный

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

Исторические драйверы DRM
Водитель Поскольку ядро Поддерживаемое оборудование Статус/Примечания
гамма 2.3.18 3Dlabs ГЛИНТ GMX 2000 Удален с версии 2.6.14. [ 115 ]
ффб 2.4 Creator/Creator3D (используется рабочими станциями Sun Microsystems Ultra ) Удален с версии 2.6.21. [ 116 ]
tdfx 2.4 3dfx Банши/ Вуду3 + Удален с версии 6.3. [ 117 ]
те 2.4 Матрокс G200 / G400 /G450 Удален с версии 6.3. [ 118 ]
р128 2.4 И Ярость 128 Удален с версии 6.3. [ 119 ]
i810 2.4 Интел i810 Удален с версии 6.3. [ 120 ]
сестренка 2.4.17 СИС 300/630/540 ​ Удален с версии 6.3. [ 121 ]
i830 2.4.20 Интел 830М/845Г/852ГМ/855ГМ/865Г Удален с версии 2.6.39. [ 122 ] (заменен драйвером i915)
с помощью 2.6.13 [ 123 ] ВИА Унихром /Унихром Про Удален с версии 6.3. [ 124 ]
дикий 2.6.14 [ 125 ] S3 Graphics Savage 3D/MX/IX/4/SuperSavage/Pro/Twister Удален с версии 6.3. [ 126 ]

Разработка

[ редактировать ]

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

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

История

[ редактировать ]

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

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

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

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

Возрастающая сложность управления видеопамятью привела к появлению нескольких подходов к решению этого вопроса. Первой попыткой стал менеджер памяти 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 года. [ 141 ] Между тем, TTM пришлось ждать до сентября 2009 года, чтобы быть окончательно объединенным с Linux 2.6.31 в соответствии с требованием нового драйвера Radeon KMS DRM. [ 142 ]

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

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

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

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

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

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

Принятие

[ редактировать ]

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

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

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ «Ядро Linux/драйверы/gpu/drm/README.drm» . ядро.орг . Архивировано из оригинала 26 февраля 2014 г. Проверено 26 февраля 2014 г.
  2. ^ Перейти обратно: а б Уйтерхувен, Герт. «Устройство кадрового буфера» . Кернел.орг . Проверено 28 января 2015 г.
  3. ^ Перейти обратно: а б с Уайт, Томас. «Как работают DRI и DRM» . Проверено 22 июля 2014 г.
  4. ^ Фейт, Рикард Э. (11 мая 1999 г.). «Диспетчер прямого рендеринга: поддержка ядра для инфраструктуры прямого рендеринга» . Проверено 12 мая 2016 г.
  5. ^ Перейти обратно: а б с д и ж г час Корбет, Джонатан (6 ноября 2007 г.). «Управление памятью графических процессоров» . LWN.net . Проверено 23 июля 2014 г. .
  6. ^ Перейти обратно: а б с д и ж г Паккард, Кейт; Анхольт, Эрик (13 мая 2008 г.). «GEM — Менеджер графического выполнения» . список рассылки dri-devel . Проверено 23 июля 2014 г. .
  7. ^ Перейти обратно: а б с Эйрли, Дэйв (12 марта 2010 г.). «Разгрузка графического процессора — ПРАЙМ — доказательство концепции» . Архивировано из оригинала 10 февраля 2015 года . Проверено 10 февраля 2015 г.
  8. ^ Перейти обратно: а б с д и Китчинг, Саймон. «Модули ядра DRM и KMS» . Проверено 13 мая 2016 г.
  9. ^ Перейти обратно: а б с д и Херрманн, Дэвид (1 сентября 2013 г.). «Разделение узлов устройств DRM и KMS» . Проверено 23 июля 2014 г. .
  10. ^ «README.rst — mesa/drm — заголовки и модули ядра Direct Rendering Manager» . 21 марта 2020 г. Архивировано из оригинала 21 марта 2020 г.
  11. ^ Перейти обратно: а б Эйрли, Дэйв (4 сентября 2004 г.). «Новый предлагаемый дизайн интерфейса DRM» . dri-devel (список рассылки).
  12. ^ Перейти обратно: а б с д и ж г Перес, Мартин; Равье, Тимоти (2 февраля 2013 г.). «DRI-next/DRM2: обзор графического стека Linux и его безопасности» (PDF) . Проверено 13 мая 2016 г.
  13. ^ Хёгсберг, Кристиан (4 сентября 2008 г.). «Расширение DRI2 – Версия 2.0» . X.Орг . Проверено 23 мая 2016 г.
  14. ^ Перейти обратно: а б с д и ж Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Вуннер, Лукас. «Руководство разработчика драйверов графического процессора Linux — Управление памятью» . Проверено 31 августа 2016 г.
  15. ^ Веттер, Дэниел. «Ускоренный курс i915/GEM Дэниела Веттера» . Центр технологий открытого исходного кода Intel . Проверено 31 января 2015 г. GEM по существу имеет дело с объектами графического буфера (которые могут содержать текстуры, буферы рендеринга, шейдеры или все виды других объектов состояния и данных, используемых графическим процессором).
  16. ^ Перейти обратно: а б с Веттер, Дэниел (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. ^ Перейти обратно: а б Паккард, Кейт (4 июля 2008 г.). «обновление драгоценных камней» . Проверено 25 апреля 2016 г.
  21. ^ "Справочная страница drm-memory" . Руководства по Ubuntu . Проверено 29 января 2015 г. Многие современные высокопроизводительные графические процессоры оснащены собственными диспетчерами памяти. Они даже включают в себя несколько разных кэшей, которые необходимо синхронизировать во время доступа. [...]. Таким образом, управление памятью на графических процессорах сильно зависит от драйверов и оборудования.
  22. ^ «Руководство разработчика Intel Graphics Media Accelerator» . Корпорация Интел . Проверено 24 ноября 2015 г.
  23. ^ Перейти обратно: а б с Ларабель, Майкл (26 августа 2008 г.). «Менеджер TTM для Radeon, модифицированный GEM» . Фороникс . Проверено 24 апреля 2016 г.
  24. ^ Перейти обратно: а б с Корбет, Джонатан (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. ^ Перейти обратно: а б с д «Linux 2.6.29 — Настройка режима ядра» . Ядро Linux для новичков . Проверено 19 ноября 2015 г.
  31. ^ «Оборудование VGA» . OSDev.org . Проверено 23 ноября 2015 г.
  32. ^ Ратманн, Б. (15 февраля 2008 г.). «Государство Нуво, часть I» . LWN.net . Проверено 23 ноября 2015 г. Видеокарты программируются разными способами, но большая часть инициализации и настройки режима выполняется через ввод-вывод, отображаемый в памяти. Это всего лишь набор регистров, доступных ЦП через его стандартное адресное пространство памяти. Регистры в этом адресном пространстве разделены на диапазоны, относящиеся к различным функциям видеокарты, таким как настройка режима, управление выходом или конфигурация часов.
  33. ^ Перейти обратно: а б с д и Пааланен, Пекка (5 июня 2014 г.). «От предыстории до конца глобальной термоядерной войны» . Проверено 29 июля 2014 г.
  34. ^ "Справочная страница drm-kms" . Руководства по Ubuntu . Проверено 19 ноября 2015 г.
  35. ^ Корбет, Джонатан (13 января 2010 г.). «Конец настройки режима пользовательского пространства?» . LWN.net . Проверено 20 ноября 2015 г.
  36. ^ Перейти обратно: а б «Обсуждение конструкции настройки режима» . 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 г.). «Kernel Summit: Видеодрайверы» . LWN.net . Проверено 23 ноября 2015 г.
  41. ^ Перейти обратно: а б «Fedora — Возможности/KernelModeSetting» . Проект Федора . Проверено 20 ноября 2015 г. Исторически сложилось так, что X-сервер отвечал за сохранение состояния вывода при запуске, а затем за его восстановление при переключении обратно в текстовый режим. Быстрое переключение пользователей осуществлялось с помощью переключателя VT, поэтому при выходе из X-сервера первого пользователя мигало один раз, чтобы перейти в текстовый режим, а затем сразу же мигало снова, чтобы перейти к сеансу второго пользователя.
  42. ^ Перейти обратно: а б с д и Барнс, Джесси (17 мая 2007 г.). «[RFC] улучшение графической подсистемы ядра» . linux-kernel (список рассылки).
  43. ^ Перейти обратно: а б с «DrmModesetting — Улучшение графики ядра» . ДРИ Вики . Проверено 23 ноября 2015 г.
  44. ^ Перейти обратно: а б с д и Паккард, Кейт (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. ^ Перейти обратно: а б с д и ж г Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Вуннер, Лукас. «Руководство разработчика драйверов графического процессора Linux — Инициализация и очистка KMS» . Проверено 31 августа 2016 г.
  50. ^ Перейти обратно: а б «Видеокарты» . X.Org Wiki . Проверено 11 апреля 2016 г.
  51. ^ Перейти обратно: а б Дойчер, Алекс (15 апреля 2010 г.). «Заметки об аппаратном обеспечении дисплея Radeon» . Архивировано из оригинала 5 апреля 2016 года . Проверено 8 апреля 2016 г.
  52. ^ Перейти обратно: а б с д и Веттер, Дэниел (5 августа 2015 г.). «Обзор конструкции настройки атомарного режима, часть 1» . LWN.net . Проверено 7 мая 2016 г.
  53. ^ Перейти обратно: а б Рединг, Тьерри (1 февраля 2015 г.). «Атомная настройка режима» (PDF) . Архив ФОСДЕМ . Проверено 7 мая 2016 г.
  54. ^ Веттер, Дэниел (12 августа 2015 г.). «Обзор конструкции настройки атомарного режима, часть 2» . LWN.net . Проверено 7 мая 2016 г.
  55. ^ Перейти обратно: а б с Херрманн, Дэвид (29 мая 2013 г.). «Узлы рендеринга и модсета DRM» . Проверено 21 июля 2014 г.
  56. ^ Перейти обратно: а б с д Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Вуннер, Лукас. «Руководство разработчика драйверов графического процессора Linux — узлы рендеринга» . Проверено 31 августа 2016 г.
  57. ^ Перейти обратно: а б Дойчер, Алекс (20 апреля 2015 г.). «Первоначальный выпуск драйвера amdgpu» . dri-devel (список рассылки).
  58. ^ Перейти обратно: а б «Linux 2.6.33 — Nouveau, драйвер для видеокарт Nvidia» . Ядро Linux для новичков . Проверено 26 апреля 2016 г.
  59. ^ Перейти обратно: а б «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 для Snapdragon» . Кернел.орг . Проверено 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: Armada: Добавить драйвер 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. ^ Перейти обратно: а б с Эйрли, Дэйв (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. ^ Перейти обратно: а б с Ларабель, Майкл (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/imagination: добавить скелетный драйвер PowerVR» . git.kernel.org . Проверено 27 мая 2024 г.
  112. ^ Ларабель, Майкл (23 ноября 2023 г.). «Драйвер графического процессора с открытым исходным кодом Imagination PowerVR будет представлен в Linux 6.8» . Фороникс . Проверено 27 мая 2024 г.
  113. ^ «drm/xe: Представляем новый драйвер DRM для графических процессоров Intel» . git.kernel.org . Проверено 27 мая 2024 г.
  114. ^ Ларабель, Майкл (15 декабря 2023 г.). «Новый графический драйвер ядра Intel «Xe» представлен раньше Linux 6.8» . Фороникс . Проверено 27 мая 2024 г.
  115. ^ «drm: удалить драйвер гаммы» . Кернел.орг . Проверено 27 января 2015 г.
  116. ^ «[DRM]: удалить код драйвера sparc64 FFB, который так и не был построен» . Кернел.орг . Проверено 27 января 2015 г.
  117. ^ «drm: удалить устаревший драйвер-tdfx» . Кернел.орг . Проверено 23 февраля 2024 г.
  118. ^ «drm: Удалить устаревший драйвер-mga» . Кернел.орг . Проверено 23 февраля 2024 г.
  119. ^ «drm: Удалить устаревший драйвер-r128» . Кернел.орг . Проверено 23 февраля 2024 г.
  120. ^ «drm: удалить устаревший драйвер-i810» . Кернел.орг . Проверено 23 февраля 2024 г.
  121. ^ «drm: Удалить устаревший драйвер-sis» . Кернел.орг . Проверено 23 февраля 2024 г.
  122. ^ «drm: удалить драйвер i830» . Кернел.орг . Проверено 27 января 2015 г.
  123. ^ «drm: Добавить через поддержку unichrome» . Кернел.орг . Проверено 27 января 2015 г.
  124. ^ «drm: Удалить устаревший драйвер-via» . Кернел.орг . Проверено 23 февраля 2024 г.
  125. ^ «drm: добавить дикого драйвера» . Кернел.орг . Проверено 27 января 2015 г.
  126. ^ "drm: Удалить устаревший драйвер-дикарь" . Кернел.орг . Проверено 23 февраля 2024 г.
  127. ^ «Список сопровождающих ядра Linux» . Кернел.орг . Проверено 14 июля 2014 г.
  128. ^ «репозиторий libdrm git» . Проверено 23 июля 2014 г. .
  129. ^ «Первая версия DRI драйвера 3dfx» . Меса 3D . Проверено 15 июля 2014 г.
  130. ^ «Импортировать 2.3.18pre1» . История Linux в формате репозитория GIT 1992–2010 (2010) . Проверено 15 июля 2014 г.
  131. ^ Торвальдс, Линус. «Исходный код Linux 2.4.0» . Кернел.орг . Проверено 29 июля 2014 г.
  132. ^ Эйрли, Дэйв (30 декабря 2004 г.). «[bk pull] ядро/раскол личности» . linux-kernel (список рассылки).
  133. ^ Торвальдс, Линус (11 января 2005 г.). «Линукс 2.6.11-rc1» . linux-kernel (список рассылки).
  134. ^ Геттис, Джеймс; Паккард, Кейт (15 июня 2004 г.). «(Ре)Архитектура системы X Window» . Проверено 30 апреля 2016 г.
  135. ^ Смирл, Джон (30 августа 2005 г.). «Состояние графики Linux» . Проверено 30 апреля 2016 г. Я считаю, что лучшим решением этой проблемы будет предоставление ядром единого комплексного драйвера устройства для каждой части видеооборудования. Это означает, что конфликтующие драйверы, такие как fbdev и DRM, должны быть объединены в сотрудничающую систему. Это также означает, что следует запретить использование оборудования из пользовательского пространства во время загрузки драйвера устройства на основе ядра.
  136. ^ Верхаген, Люк (2 марта 2006 г.). «X и настройка режима: иллюстрация атрофии» (PDF) . Проверено 30 апреля 2016 г.
  137. ^ Глисс, Джером (4 декабря 2007 г.). «Настройка режима ядра Radeon» . Проверено 30 апреля 2016 г.
  138. ^ Ларабель, Майкл (1 октября 2008 г.). «Состояние настройки режима ядра» . Фороникс . Проверено 30 апреля 2016 г.
  139. ^ Паккард, Кейт (21 июля 2008 г.). «Статус выхода X июль 2008 г.» . Проверено 1 мая 2016 г.
  140. ^ «drm: реорганизовать дерево Drm, чтобы оно было более перспективным» . Кернел.орг .
  141. ^ «Linux 2.6.28 — Диспетчер памяти GEM для памяти графического процессора» . Ядро Linux для новичков . Проверено 23 июля 2014 г. .
  142. ^ «drm: добавить подсистему диспетчера памяти TTM GPU» . Кернел.орг .
  143. ^ «DRM: добавить поддержку настройки режима» . Кернел.орг .
  144. ^ «DRM: i915: добавить поддержку настройки режима» . Кернел.орг .
  145. ^ Анхольт, Эрик (22 декабря 2008 г.). «[ОБЪЯВЛЕНИЕ] libdrm-2.4.3» . dri-devel (список рассылки).
  146. ^ Барнс, Джесси (20 октября 2008 г.). «[ОБЪЯВЛЕНИЕ] xf86-video-intel 2.5.0» . xorg-announce (список рассылки).
  147. ^ «Linux 2.6.31 — поддержка настройки режима ядра ATI Radeon» . Ядро Linux для новичков . Архивировано из оригинала 5 ноября 2015 года . Проверено 28 апреля 2016 г.
  148. ^ Торвальдс, Линус (9 сентября 2009 г.). «Линукс 2.6.31» . linux-kernel (список рассылки).
  149. ^ «drm/radeon: ввести настройку режима ядра для оборудования Radeon» . Кернел.орг .
  150. ^ «Необычный спутник развития Nouveau # 40» . Проект «Нуво» . Проверено 3 мая 2016 г.
  151. ^ «Linux 2.6.33 — Улучшения графики» . Ядро Linux для новичков . Проверено 28 апреля 2016 г.
  152. ^ "drm/kms: добавить перелистывание страниц ioctl" . Кернел.орг .
  153. ^ «Linux 2.6.38 — Графика» . Ядро Linux для новичков . Проверено 28 апреля 2016 г.
  154. ^ Эйрли, Дэйв (21 декабря 2009 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.17» . dri-devel (список рассылки).
  155. ^ «drm: немое сканирование create/mmap для intel/radeon (v3)» . Кернел.орг .
  156. ^ «Linux 2 6 39-DriversArch» . Ядро Linux для новичков . Проверено 19 апреля 2016 г.
  157. ^ Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Вуннер, Лукас. «Руководство разработчика драйверов графического процессора Linux — Тупые объекты буфера» . Проверено 31 августа 2016 г.
  158. ^ Уилсон, Крис (11 апреля 2011 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.25» . dri-devel (список рассылки).
  159. ^ Барнс, Джесси (25 апреля 2011 г.). «[RFC] drm: добавление наложений как первоклассных объектов KMS» . dri-devel (список рассылки).
  160. ^ Барнс, Джесси (13 мая 2011 г.). «[RFC] drm: добавление наложений как первоклассных объектов KMS» . dri-devel (список рассылки).
  161. ^ «drm: добавить поддержку самолетов v3» . Кернел.орг .
  162. ^ «drm: добавьте общие ioctls для получения/установки свойств любого объекта» . Кернел.орг .
  163. ^ Видавски, Бен (27 июня 2012 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.36» . xorg-announce (список рассылки).
  164. ^ Ларабель, Майкл. «Проверка концепции: рендеринг с использованием нескольких графических процессоров с открытым исходным кодом!» . Фороникс . Проверено 14 апреля 2016 г.
  165. ^ Ларабель, Майкл (23 февраля 2012 г.). «Поддержка DRM Base PRIME — часть работы VGEM» . Фороникс . Проверено 14 апреля 2016 г.
  166. ^ Эйрли, Дэйв (27 марта 2012 г.). «[ИСПРАВЛЕНИЕ] drm: базовая поддержка prime/dma-buf (v5)» . dri-devel (список рассылки).
  167. ^ Ларабель, Майкл (30 марта 2012 г.). «Горящая минута для Linux 3.4: поддержка DMA-BUF PRIME» . Фороникс . Проверено 15 апреля 2016 г.
  168. ^ «drm: базовая поддержка prime/dma-buf (v5)» . Кернел.орг .
  169. ^ «Linux 3.4 DriverArch» . Ядро Linux для новичков . Проверено 15 апреля 2016 г.
  170. ^ Анхольт, Эрик (10 мая 2012 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.34» . dri-devel (список рассылки).
  171. ^ Ларабель, Майкл (12 мая 2012 г.). «DMA-BUF PRIME собирается вместе для Linux 3.5» . Фороникс . Проверено 15 апреля 2016 г.
  172. ^ «Linux 3.5 DriverArch» . Ядро Linux для новичков . Проверено 15 апреля 2016 г.
  173. ^ Корбет, Джонатан (11 сентября 2013 г.). «Окно слияния 3.12, часть 2» . LWN.net . Проверено 21 июля 2014 г.
  174. ^ «drm: реализовать экспериментальные узлы рендеринга» . Кернел.орг .
  175. ^ «drm/i915: Поддержка узлов рендеринга» . Кернел.орг .
  176. ^ «drm/radeon: поддержка узлов рендеринга» . Кернел.орг .
  177. ^ «drm/nouveau: Поддержка узлов рендеринга» . Кернел.орг .
  178. ^ Ропер, Мэтт (7 марта 2014 г.). «[RFCv2 00/10] Поддержка универсальной плоскости» . dri-devel (список рассылки).
  179. ^ Ларабель, Майкл (2 апреля 2014 г.). «Универсальный набор поддержки самолетов для Linux 3.15» . Фороникс . Проверено 14 апреля 2016 г.
  180. ^ Ланкхорст, Мартен (25 июля 2014 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.55» . dri-devel (список рассылки).
  181. ^ Перейти обратно: а б Веттер, Дэниел (7 августа 2014 г.). «Отличная штука для 3.17» . Проверено 14 апреля 2016 г.
  182. ^ Барнс, Джесси (15 февраля 2012 г.). «[RFC] drm: API установки атомарного режима» . dri-devel (список рассылки).
  183. ^ Сюрьяля, Вилле (24 мая 2012 г.). «[RFC][PATCH 0/6] WIP: drm: идея настройки атомарного режима» . dri-devel (список рассылки).
  184. ^ Кларк, Роб (9 сентября 2012 г.). «[RFC 0/9] ядерный переворот страницы» . dri-devel (список рассылки).
  185. ^ Кларк, Роб (6 октября 2013 г.). «[RFCv1 00/12] Атомный/ядерный набор режимов/переворот страницы» . dri-devel (список рассылки).
  186. ^ Веттер, Дэниел (3 февраля 2016 г.). «Примите эпоху атомного дисплея» (PDF) . Проверено 4 мая 2016 г.
  187. ^ Веттер, Дэниел (2 ноября 2014 г.). «Поддержка атомарного режима набора драйверов KMS» . Проверено 4 мая 2016 г.
  188. ^ Эйрли, Дэйв (14 декабря 2014 г.). «[git pull] drm для 3.19-rc1» . dri-devel (список рассылки).
  189. ^ Веттер, Дэниел (28 января 2015 г.). «Обновление для обновлений Atomic Display» . Проверено 4 мая 2016 г.
  190. ^ Эйрли, Дэйв (15 февраля 2015 г.). «[git pull] drm pull для 3.20-rc1» . dri-devel (список рассылки).
  191. ^ «Linux 4.0 — DriverArch — Графика» . Ядро Linux для новичков . Проверено 3 мая 2016 г.
  192. ^ «Linux 4.2 — API атомной настройки мод включен по умолчанию» . Ядро Linux для новичков . Проверено 3 мая 2016 г.
  193. ^ Великов, Эмиль (29 июня 2015 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.62» . dri-devel (список рассылки).
  194. ^ Веттер, Дэниел (6 июня 2016 г.). «Удивительные атомные достижения» . Проверено 7 июня 2016 г. сейчас 17 драйверов, поддерживающих атомарную настройку мод, объединены в подсистему DRM
  195. ^ Стоун, Дэниел (20 марта 2018 г.). «Новая эра низкоуровневой графики Linux. Часть 1» . Проверено 5 мая 2018 г.
  196. ^ Херрманн, Дэвид (10 декабря 2012 г.). «Введение в KMSCON» . Проверено 22 ноября 2015 г.
  197. ^ «Драйвер Linux, Solaris и FreeBSD 358.09 (бета)» . 10 декабря 2015 г.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Direct_Rendering_Manager&oldid=1231601663#Atomic_mode_setting"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: eb46dcb9875f577698913056280568e4__1719629760
URL1:https://arc.ask3.ru/arc/aa/eb/e4/eb46dcb9875f577698913056280568e4.html
Заголовок, (Title) документа по адресу, URL1:
Direct Rendering Manager - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)