Менеджер прямого рендеринга ( DRM ) - это подсистема ядра Linux, отвечающая за взаимодействие с графическими процессорами современных видеокарт . DRM предоставляет API, который программы пользовательского пространства могут использовать для отправки команд и данных на GPU и выполнения таких операций, как настройка режима отображения. DRM была впервые разработана в качестве ядра космического компонента X Server Infrastructure Direct Rendering , [1] , но с тех пор она была использована другими графическими альтернативами стека , такие как Wayland .
Автор (ы) оригинала | kernel.org и freedesktop.org |
---|---|
Разработчики) | kernel.org и freedesktop.org |
Написано в | C |
Тип | |
Лицензия |
|
Веб-сайт | dri |
Программы пользовательского пространства могут использовать DRM API, чтобы дать команду графическому процессору выполнять 3D-рендеринг и декодирование видео с аппаратным ускорением , а также вычисления GPGPU .
Обзор
Ядро Linux уже имело API под названием fbdev , используемое для управления видеобуфером в виде графического адаптера , [2] , но он не может быть использован для обработки потребностей современного 3D-ускорение GPU основанного видеоадаптера. Эти устройства обычно требуют настройки и управления очередью команд в их собственной памяти для отправки команд на графический процессор, а также требуют управления буферами и свободным пространством в этой памяти. [3] Первоначально программы пользовательского пространства (такие как X-сервер ) напрямую управляли этими ресурсами, но обычно они действовали так, как если бы они были единственными, кто имел к ним доступ. Когда две или более программы пытались управлять одним и тем же оборудованием одновременно и настраивали свои ресурсы каждая по-своему, в большинстве случаев они заканчивались катастрофически. [3]
Диспетчер прямого рендеринга был создан, чтобы позволить нескольким программам совместно использовать ресурсы видеооборудования. [4] DRM получает эксклюзивный доступ к графическому процессору и отвечает за инициализацию и поддержание очереди команд, памяти и любых других аппаратных ресурсов. Программы, желающие использовать графический процессор, отправляют запросы в DRM, который действует как арбитр и заботится о предотвращении возможных конфликтов.
Объем DRM был расширен с годами, чтобы охватить больше функций, которые ранее обрабатывались программами пользовательского пространства, таких как управление буфером кадра и установка режима , объекты совместного использования памяти и синхронизация памяти. [5] [6] Некоторым из этих расширений были даны определенные имена, такие как Graphics Execution Manager (GEM) или настройка режима ядра (KMS), и терминология преобладает, когда конкретно упоминается функциональность, которую они предоставляют. Но на самом деле они являются частями всей подсистемы DRM ядра.
Тенденция включать в компьютер два графических процессора - дискретный и интегрированный - привела к новым проблемам, таким как переключение графических процессоров, которые также необходимо было решать на уровне DRM. Чтобы соответствовать технологии Nvidia Optimus , DRM была предоставлена возможность разгрузки графического процессора, называемая PRIME. [7]
Архитектура программного обеспечения
Менеджер прямого рендеринга находится в пространстве ядра , поэтому программы пользовательского пространства должны использовать системные вызовы ядра для запроса его служб. Однако DRM не определяет свои собственные настраиваемые системные вызовы. Вместо этого он следует принципу Unix « все является файлом », чтобы раскрыть графические процессоры через пространство имен файловой системы, используя файлы устройств в /dev
иерархии. Каждый графический процессор, обнаруженный DRM, называется устройством DRM , и для взаимодействия с ним создается файл устройства (где X - порядковый номер). [8] [9] Программы пользовательского пространства, которые хотят взаимодействовать с GPU, должны открывать этот файл и использовать вызовы ioctl для связи с DRM. Разные ioctl соответствуют разным функциям DRM API ./dev/dri/cardX
Библиотека называется libdrm была создана , чтобы облегчить интерфейс пользовательского пространства программ с подсистемой DRM. Эта библиотека является просто оболочкой, которая предоставляет функцию, написанную на C, для каждого ioctl DRM API, а также константы, структуры и другие вспомогательные элементы. [10] Использование 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
В DRM API есть несколько операций (ioctls), которые либо в целях безопасности, либо из-за проблем параллелизма должны быть ограничены для использования одним процессом пользовательского пространства на устройстве. [8] Для реализации этого ограничения DRM ограничивает такие ioctl вызовом только процессом, который считается «ведущим» устройства DRM, обычно называемым DRM-Master . Только один из всех процессов, у которых открыт узел устройства, будет иметь дескриптор файла, помеченный как главный, особенно первый, вызывающий SET_MASTER ioctl. Любая попытка использовать один из этих ограниченных ioctl без DRM-Master вернет ошибку. Процесс также может отказаться от своей ведущей роли и позволить другому процессу ее получить, вызвав /dev/dri/cardX
DROP_MASTER ioctl.
X Server -или любой другой сервер отображения -это обычно процесс , который приобретает статус 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 нуждались в оптимальном способе совместного использования буферов вне экрана с менеджером композитинга . Эти требования привели к разработке новых методов управления графическими буферами внутри ядра. Графика Execution менеджер (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 решили предоставить программам пользовательского пространства GEM API, но внутри они реализовали другой диспетчер памяти, лучше подходящий для их конкретного оборудования и архитектуры памяти. [23]
GEM API также предоставляет ioctls для управления потоком выполнения (буферы команд), но они специфичны для Intel и предназначены для использования с Intel i915 и более поздними графическими процессорами. [6] Ни один другой драйвер DRM не пытался реализовать какую-либо часть GEM API, кроме специфичных для управления памятью ioctl.
Карты таблиц переводов
Карты таблиц трансляции (TTM) - это название универсального менеджера памяти для графических процессоров, который был разработан до GEM. [5] [14] Он был специально разработан для управления различными типами памяти, к которой может обращаться графический процессор, включая выделенную видеопамять (обычно устанавливаемую на видеокарте) и системную память, доступную через блок управления памятью ввода-вывода, называемый Graphics Таблица переназначения адресов (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 Buffer Sharing (часто сокращенно DMA-BUF) является Linux Kernel внутреннего 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 .
Настройка режима ядра
Для правильной работы видеокарта или графический адаптер должны установить режим - сочетание разрешения экрана , глубины цвета и частоты обновления - который находится в пределах диапазона значений, поддерживаемых им самим и подключенным экраном дисплея . Эта операция называется режим установления , [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]
- Процесс приостановки / возобновления должен полагаться на инструменты пользовательского пространства для восстановления предыдущего режима. Один единственный сбой или сбой одной из этих программ может оставить систему без рабочего дисплея из-за неправильной конфигурации режима и, следовательно, непригодной для использования.
- Ядро также не могло отображать сообщения об ошибках или отладочных сообщениях, когда экран был в графическом режиме - например, когда работал X - поскольку ядро знало только стандартные текстовые режимы VESA BIOS.
- Более насущной проблемой было распространение графических приложений в обход X-сервера и появление других альтернативных графических стеков для X, что еще больше расширило дублирование кода установки режима в системе.
Для решения этих проблем код установки режима был перемещен в одно место внутри ядра, в частности, в существующий модуль DRM. [36] [37] [44] [42] [43] Затем каждый процесс, включая X-сервер, должен иметь возможность отдавать команду ядру на выполнение операций установки режима, и ядро будет гарантировать, что параллельные операции не будут привести к противоречивому состоянию. Новый API ядра и код, добавленные в модуль DRM для выполнения этих операций по настройке режима, назывались Kernel Mode-Setting (KMS). [30]
Настройка режима ядра дает несколько преимуществ. Самым незамедлительным, конечно же, является удаление повторяющегося кода установки режима как из ядра (консоль Linux, fbdev), так и из пользовательского пространства (драйверы X Server DDX). KMS также упрощает написание альтернативных графических систем, которым теперь не нужно реализовывать собственный код установки режима. [42] [43] Предоставляя централизованное управление режимами, KMS решает проблемы мерцания при переключении между консолью и X, а также между различными экземплярами X (быстрое переключение пользователей). [41] [44] Поскольку он доступен в ядре, его также можно использовать в начале процесса загрузки, что позволяет избежать мерцания из-за изменений режима на этих ранних этапах.
Тот факт, что KMS является частью ядра, позволяет ему использовать ресурсы, доступные только в пространстве ядра, такие как прерывания . [45] Например, восстановление режима после приостановки / возобновления процесса значительно упрощается за счет управления самим ядром и, в частности, повышает безопасность (больше нет инструментов пользовательского пространства, требующих полномочий root). Ядро также позволяет легко подключать новые устройства отображения, решая давнюю проблему. [45] Установка режима также тесно связана с управлением памятью, поскольку фреймбуферы в основном являются буферами памяти, поэтому настоятельно рекомендуется тесная интеграция с менеджером графической памяти. Это основная причина, по которой код установки режима ядра был включен в DRM, а не как отдельная подсистема. [44]
Чтобы избежать нарушения обратной совместимости DRM API, настройка режима ядра предоставляется в качестве дополнительной функции некоторых драйверов DRM. [46] Любой драйвер DRM может предоставить DRIVER_MODESET, когда он регистрируется в ядре DRM, чтобы указать, что поддерживает KMS API. [8] Драйверы, реализующие настройку режима ядра, часто называют драйверами KMS, чтобы отличить их от устаревших - без KMS - драйверов DRM.
KMS был принят до такой степени, что некоторые драйверы, в которых отсутствует 3D-ускорение (или для которых поставщик оборудования не хочет предоставлять или реализовывать его), тем не менее, реализуют KMS API без остальной части DRM API.
Модель устройства KMS
KMS моделирует устройства вывода и управляет ими как серию абстрактных аппаратных блоков, обычно присутствующих в конвейере вывода дисплея контроллера дисплея . Эти блоки: [47]
- КРТЦ : каждый КРТЦ (от ЭЛТ - контроллера [48] [33] ) представляет собой scanout двигатель контроллера дисплея, указывая на scanout буфера ( фреймбуфера ). [47] Целью CRTC является считывание пиксельных данных, находящихся в текущий момент в буфере сканирования, и генерация из них сигнала синхронизации видеорежима с помощью схемы ФАПЧ . [49] Количество доступных CRTC определяет, сколько независимых устройств вывода может обрабатывать оборудование одновременно, поэтому для использования конфигураций с несколькими головками требуется по крайней мере один CRTC на каждое устройство отображения. [47] Два или более CRTC могут также работать в режиме клонирования, если они сканируют из одного и того же фреймбуфера, чтобы отправить одно и то же изображение на несколько устройств вывода. [49] [48]
- Разъемы : разъем представляет, куда контроллер дисплея отправляет видеосигнал от операции сканирования для отображения. Обычно концепция разъема KMS соответствует физическому разъему ( VGA , DVI , FPD-Link , HDMI , DisplayPort , S-Video , ...) в оборудовании, где находится устройство вывода ( монитор , панель ноутбука , ... ) прикреплен постоянно или может быть временно прикреплен. Информация, относящаяся к текущему физически подключенному устройству вывода, такая как состояние подключения, данные EDID , состояние DPMS или поддерживаемые видеорежимы, также хранится в разъеме. [47]
- Кодеры : контроллер дисплея должен кодировать сигнал синхронизации видеорежима от CRTC, используя формат, подходящий для предполагаемого разъема. [47] Кодер представляет собой аппаратный блок, способный выполнять одно из этих кодировок. Примерами кодирования для цифровых выходов являются TMDS и LVDS ; для аналоговых выходов, таких как VGA и TV out , обычно используются специальные блоки DAC . Разъем может принимать сигнал только от одного кодировщика за раз [47], и каждый тип разъема поддерживает только некоторые кодировки. Также могут быть дополнительные физические ограничения, в соответствии с которыми не каждый CRTC подключается ко всем доступным кодировщикам, ограничивая возможные комбинации CRTC-кодировщик-коннектор.
- Плоскости : плоскость - это не аппаратный блок, а объект памяти, содержащий буфер, из которого загружается механизм сканирования (CRTC). Плоскость, которая содержит буфер кадра , называется первичной плоскостью , и каждый CRTC должен иметь один связанный [47], поскольку он является источником CRTC для определения видеорежима - разрешения дисплея (ширина и высота), размер пикселя, формат пикселя, частота обновления и т. д. CRTC может также иметь связанные с ним плоскости курсора, если контроллер дисплея поддерживает аппаратные наложения курсора, или вторичные плоскости, если он может сканировать из дополнительных аппаратных наложений и составлять или смешивать "на лету" отправленное окончательное изображение к устройству вывода. [33]
Атомный дисплей
В последние годы прилагаются постоянные усилия по обеспечению атомарности некоторых регулярных операций, относящихся к KMS API, в частности , настройки режима и операций перелистывания страниц . [33] [50] Этот усовершенствованный KMS API называется атомарным отображением (ранее называвшимся атомарной настройкой режима и атомарным или ядерным переворотом страницы ).
Цель атомарной настройки режима - обеспечить правильное изменение режима в сложных конфигурациях с множеством ограничений, избегая промежуточных шагов, которые могут привести к несогласованному или недопустимому состоянию видео; [50] это также позволяет избежать рискованных состояний видео, когда необходимо отменить неудачный процесс установки режима («откат»). [51] : 9 Атомарная настройка режима позволяет заранее узнать, подходит ли конкретная конфигурация режима, предоставляя возможности тестирования режима. [50] Когда атомарный режим протестирован и его валидность подтверждена, его можно применить с помощью одной неделимой (атомарной) операции фиксации . Операции тестирования и фиксации предоставляются одним и тем же новым ioctl с разными флагами.
С другой стороны, атомарный переворот страницы позволяет обновлять несколько плоскостей на одном и том же выходе (например, первичную плоскость, плоскость курсора и, возможно, некоторые наложения или вторичные плоскости), все синхронизированные в одном интервале VBLANK , обеспечивая правильное отображение без разрывов. [51] : 9,14 [50] Это требование особенно актуально для мобильных и встроенных контроллеров дисплеев, которые обычно используют несколько плоскостей / наложений для экономии энергии.
Новый атомарный API построен на старом KMS API. Он использует ту же модель и объекты (CRTC, кодировщики, соединители, плоскости и т. Д.), Но с увеличивающимся числом свойств объекта, которые можно изменять. [50] Атомарная процедура основана на изменении соответствующих свойств для создания состояния, которое мы хотим протестировать или зафиксировать. Свойства, которые мы хотим изменить, зависят от того, хотим ли мы выполнить настройку режима (в основном CRTC, свойства кодировщиков и соединителей) или переворачивание страницы (обычно свойства плоскостей). Ioctl одинаков для обоих случаев, разница заключается в списке свойств, передаваемых с каждым из них. [52]
Узлы рендеринга
В исходном API DRM устройство DRM используется как для привилегированных (установка режима, другое управление отображением), так и для непривилегированных (рендеринг, вычисление GPGPU ). [9] По соображениям безопасности открытие связанного файла устройства DRM требует специальных привилегий, «эквивалентных привилегиям root». [53] Это приводит к архитектуре, в которой только некоторые надежные программы пользовательского пространства (X-сервер, графический редактор ...) имеют полный доступ к DRM API, включая привилегированные части, такие как API набора режимов. Остальные приложения пользовательского пространства, которые хотят отображать или производить вычисления GPGPU, должны быть предоставлены владельцем устройства DRM («DRM Master») посредством использования специального интерфейса аутентификации. [54] Затем аутентифицированные приложения могут отображать или производить вычисления с использованием ограниченной версии DRM API без привилегированных операций. Этот дизайн налагает серьезное ограничение: всегда должен быть работающий графический сервер (X-сервер, композитор Wayland, ...), действующий как DRM-Master устройства DRM, чтобы другим программам пользовательского пространства было разрешено использование устройства, даже в случаях, когда графический дисплей не используется, например, вычисления GPGPU. [53] [54]/dev/dri/cardX
Концепция «узлов рендеринга» пытается решить эти сценарии путем разделения API пользовательского пространства DRM на два интерфейса - один привилегированный и один непривилегированный - и используя отдельные файлы устройств (или «узлы») для каждого из них. [9] Для каждого найденного графического процессора соответствующий драйвер DRM - если он поддерживает функцию узлов визуализации - создает файл устройства , называемый узлом визуализации , в дополнение к первичному узлу . [54] [9] Клиенты, которые используют модель прямого рендеринга, и приложения, которые хотят воспользоваться вычислительными возможностями графического процессора, могут сделать это, не требуя дополнительных привилегий, просто открыв любой существующий узел рендеринга и отправив операции графического процессора с использованием ограниченного подмножества. API DRM, поддерживаемого этими узлами, при условии, что у них есть разрешения файловой системы на открытие файла устройства. Серверы отображения, композиторы и любая другая программа, для которой требуется API набора мод или любая другая привилегированная операция, должны открыть стандартный первичный узел, который предоставляет доступ к полному API DRM, и использовать его как обычно. Узлы рендеринга явно запрещают операцию мигания GEM, чтобы предотвратить совместное использование буфера с использованием небезопасных глобальных имен GEM; только файловые дескрипторы PRIME (DMA-BUF) могут использоваться для совместного использования буферов с другим клиентом, включая графический сервер. [9] [54]/dev/dri/renderDX
/dev/dri/cardX
Аппаратная поддержка
Подсистема Linux DRM включает бесплатные драйверы с открытым исходным кодом для поддержки оборудования трех основных производителей графических процессоров для настольных компьютеров (AMD, NVIDIA и Intel), а также растущего числа мобильных графических процессоров и систем на кристалле (SoC). интеграторы. Качество каждого драйвера сильно различается в зависимости от степени сотрудничества со стороны производителя и других вопросов.
Водитель | Поскольку ядро | Поддерживаемое оборудование | Поддержка поставщика | Статус / Примечания |
---|---|---|---|---|
radeon | 2.4.1 | AMD (ранее ATi) серия графических процессоров Radeon с архитектурами TeraScale и GCN 1-го и 2-го поколения . В том числе моделей R100 / 200 / в 300 / 400 , Radeon X1000 , HD 2000 / 4000 / 5 000 / 6000 / 7000 / 8000 , R5 / R7 / R9 , 200 / 300 серий и Кавери ВСУ. | да | Активный |
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 [56] [57] | Графические процессоры GeForce на базе NVIDIA Tesla , Fermi , Kepler , Maxwell , Tegra K1 , X1 SoC | Частичное | Активный |
Exynos | 3,2 [58] | SoC Exynos на базе ARM от Samsung | ||
vmwgfx | 3,2 (от постановки) [59] | Виртуальный графический процессор для VMware SVGA2 | виртуальный водитель | |
gma500 | 3.3 (от постановки) [60] [61] | Графические процессоры на базе Intel GMA 500 и других технологий Imagination Technologies ( PowerVR ) | экспериментальный 2D-драйвер KMS | |
аст | 3,5 [62] | ASpeed Technologies 2000 серии | экспериментальный | |
мгаг200 | 3,5 [63] | Серверные дисплеи Matrox MGA-G200 | Только KMS | |
шмобиль | 3,7 [64] | Renesas SH Mobile | ||
тегра | 3,8 [65] | Nvidia Tegra 20, SoC Tegra30 | да | Активный |
omapdrm | 3,9 [66] | 5 SoC Texas Instruments OMAP | ||
rcar-du | 3.11 [67] | Дисплейные блоки Renesas R-Car SoC | ||
мсм | 3,12 [68] [69] | Qualcomm «s Adreno A2xx / A3XX / A4xx GPU семейства ( Snapdragon SoC с ) [70] | ||
армада | 3,13 [71] [72] | Marvell Armada 510 SoC | ||
Bochs | 3,14 [73] | Виртуальные карты VGA с использованием интерфейса Bochs dispi vga (например, QEMU stdvga) | виртуальный водитель | |
sti | 3,17 [74] [75] | STMicroelectronics SoC серии stiH41x | ||
imx | 3,19 (от стадии) [76] [77] | SoC Freescale i.MX | ||
рок-чип | 3,19 [76] [78] | Графические процессоры на базе SoC Rockchip | Только KMS | |
amdgpu [55] | 4,2 [79] [80] | Серия графических процессоров AMD Radeon с архитектурами GCN 3-го и 4-го поколения . В том числе моделей Radeon Rx в 200 / в 300 / 400 / 500 [81] серии и Carrizo и Bristol & Stoney Ridge APUs. | да | Активный |
virtio | 4,2 [82] | драйвер виртуального графического процессора для менеджеров виртуальных машин на основе QEMU (например, KVM или Xen ) | виртуальный водитель | |
vc4 | 4,4 [83] [84] [85] | Малина Pi «s Broadcom BCM2835 и BCM2836 СнК ( VideoCore И.В. ГПУ) | ||
этнавив | 4,5 [86] [87] [88] | Ядра Vivante GPU присутствуют в нескольких SoC, таких как Marvell ARMADA и Freescale i.MX6 Series | ||
sun4i | 4,7 [89] [90] | SoC Allwinner ( графический процессор ARM Mali-400 ) | ||
кирин | 4,7 [91] [90] | HiSilicon Kirin hi6220 SoC (графический процессор ARM Mali 450-MP4 ) | ||
mediatek | 4,7 [92] [90] | MediaTek MT8173 SoC ( графический процессор Imagination PowerVR GX6250) | ||
hibmc | 4.10 [93] | HiSilicon hi1710 Huawei iBMC SoC ( ядро графического процессора Silicon Image SM750 [94] ) | Только KMS | |
vboxvideo | 4,13 (от постановки) [95] [96] | Драйвер виртуального графического процессора для VirtualBox (VBoxVGA GPU) | виртуальный водитель | |
Лима | 5,2 [97] | Графические процессоры ARM Mali 4xx | ||
жаровня | 5,2 [98] | Графические процессоры ARM Mali Txxx (Midgard) и Gxx (Bifrost) |
Существует также ряд драйверов для старого устаревшего оборудования, которые подробно описаны в следующей таблице для исторических целей. Некоторые из них все еще остались в коде ядра, но другие уже удалены.
Водитель | Поскольку ядро | Поддерживаемое оборудование | Статус / Примечания |
---|---|---|---|
гамма | 2.3.18 | 3Dlabs GLINT GMX 2000 | Удалено с 2.6.14 [99] |
ffb | 2,4 | Creator / Creator3D (используется рабочими станциями Sun Microsystems Ultra ) | Удалено с 2.6.21 [100] |
tdfx | 2,4 | 3dfx Banshee / Voodoo3 + | |
mga | 2,4 | Matrox G200 / G400 / G450 | |
r128 | 2,4 | ATI Rage 128 | |
i810 | 2,4 | Intel i810 | |
сестренка | 2.4.17 | SiS 300 / 630/540 | |
i830 | 2.4.20 | Intel 830M / 845G / 852GM / 855GM / 865G | Удалено с версии 2.6.39 [101] (заменено драйвером i915) |
через | 2.6.13 [102] | VIA Unichrome / Unichrome Pro | |
дикий | 2.6.14 [103] | S3 Графика Savage 3D / MX / IX / 4 / SuperSavage / Pro / Twister |
Разработка
Менеджер прямого рендеринга разработан в ядре Linux , и его исходный код находится в /drivers/gpu/drm
каталоге исходного кода Linux. Сопровождающим подсистемы является Дэйв Эрли, а другие специалисты по сопровождению заботятся о конкретных драйверах. [104] Как обычно при разработке ядра Linux, ответственные за DRM и участники отправляют свои патчи с новыми функциями и исправлениями ошибок основному разработчику DRM, который интегрирует их в свой собственный репозиторий Linux . Сопровождающий DRM, в свою очередь, отправляет все эти исправления, которые готовы к использованию, Линусу Торвальдсу всякий раз, когда будет выпущена новая версия Linux. Торвальдс, как главный сопровождающий всего ядра, держит последнее слово за то, подходит ли патч для включения в ядро.
По историческим причинам исходный код библиотеки libdrm поддерживается проектом Mesa . [105]
История
В 1999 году при разработке DRI для XFree86 компания Precision Insight создала первую версию DRM для видеокарт 3dfx в виде патча ядра Linux, включенного в исходный код Mesa . [106] Позже в том же году код DRM был встроен в ядро Linux 2.3.18 в каталог для символьных устройств . [107] В последующие годы количество поддерживаемых видеокарт росло. Когда в январе 2001 года был выпущен Linux 2.4.0, уже была поддержка Creative Labs GMX 2000, Intel i810, Matrox G200 / G400 и ATI Rage 128, в дополнение к картам 3dfx Voodoo3 [108], и этот список расширился в версии 2.4. x, с драйверами для карт ATI Radeon , некоторых видеокарт SiS, Intel 830M и последующих встроенных графических процессоров./drivers/char/drm/
Разделение DRM на два компонента, ядро DRM и драйвер DRM, названное разделением ядра DRM / индивидуальности, было выполнено во второй половине 2004 года [11] [109] и объединено с версией ядра 2.6.11. [110] Это разделение позволило нескольким драйверам DRM для нескольких устройств работать одновременно, открыв путь к поддержке нескольких графических процессоров.
Идея разместить весь код настройки видеорежима в одном месте внутри ядра была признана в течение многих лет [111] [112], но производители видеокарт утверждали, что единственный способ выполнить настройку режима - это использовать процедуры предоставляются сами по себе и содержатся в Video BIOS каждой видеокарты. Такой код должен был выполняться в реальном режиме x86 , что предотвращало его запуск ядром, работающим в защищенном режиме . [44] Ситуация изменилась, когда Люк Верхаген и другие разработчики нашли способ сделать настройку режима изначально, а не на основе BIOS, [113] [44] показывая, что это можно сделать, используя обычный код ядра, и заложив основы для того, что станет настройкой режима ядра . В мае 2007 года Джесси Барнс ( Intel ) опубликовала первое предложение о ЦУПЕ-переключении видеорежима API и рабочей нативную реализацию переключения видеорежима для Intel графических процессоров в драйвере i915 DRM. [42] В декабре 2007 года Джером Глисс начал добавлять код настройки режима для карт ATI в драйвер DRM Radeon. [114] [115] Работа над API и драйверами продолжалась в течение 2008 года, но была отложена из-за необходимости наличия диспетчера памяти также в пространстве ядра для обработки буферов кадра. [116]
В октябре 2008 года ядро Linux 2.6.27 претерпело серьезную реорганизацию исходного кода перед некоторыми существенными предстоящими изменениями. Дерево исходного кода DRM было перемещено в свой собственный исходный каталог, /drivers/gpu/drm/
а различные драйверы были перемещены в свои собственные подкаталоги. Заголовки также были перемещены в новый /include/drm
каталог. [117]
Возрастающая сложность управления видеопамятью привела к нескольким подходам к решению этой проблемы. Первой попыткой был менеджер памяти карт трансляции (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 года. [118] Между тем, TTM пришлось ждать до сентября 2009 года, чтобы окончательно объединиться с Linux 2.6.31 в качестве требования нового Radeon. Драйвер KMS DRM. [119]
Имея управление памятью для обработки буферных объектов, разработчики DRM могли наконец добавить в ядро уже готовый API и код для настройки режима . Этот расширенный API называется настройкой режима ядра (KMS), а драйверы, которые его реализуют, часто называют драйверами KMS . В марте 2009 года KMS был объединен с ядром Linux версии 2.6.29, [30] [120] вместе с поддержкой KMS для драйвера i915. [121] KMS API доступен для программ пользовательского пространства, начиная с libdrm 2.4.3. [122] Драйвер X.Org DDX в пользовательском пространстве для видеокарт Intel также был первым, кто использовал новые API-интерфейсы GEM и KMS. [123] Поддержка KMS для драйвера DRM radeon была добавлена в Linux 2.6.31 от сентября 2009 года. [124] [125] [126] Новый драйвер KMS radeon использовал диспетчер памяти TTM, но вместо этого предоставлял GEM-совместимые интерфейсы и ioctls. ТТМ. [23]
С 2006 года проект nouveau разрабатывал бесплатный драйвер DRM для графических процессоров NVIDIA вне официального ядра Linux. В 2010 году исходный код модерна был объединен с Linux 2.6.33 в качестве экспериментального драйвера. [56] [57] На момент слияния драйвер уже был преобразован в KMS, а за GEM API он использовал TTM в качестве диспетчера памяти. [127]
Новый KMS API, включая GEM API, стал важной вехой в развитии DRM, но не помешал усовершенствованию API в последующие годы. KMS получил поддержку страницы переворачивает в сочетании с асинхронным VBLANK уведомлений в Linux 2.6.33 [128] [129] -только для i915 драйвера, и RADEON нуво добавлена позже во время Linux 2.6.38 релиза. [130] В libdrm 2.4.17 был добавлен новый интерфейс перелистывания страниц. [131] В начале 2011 года, во время цикла выпуска Linux 2.6.39, в KMS API были добавлены так называемые немые буферы - аппаратно-независимый неускоренный способ обработки простых буферов, пригодных для использования в качестве буферов кадра. [132] [133] Цель заключалась в том, чтобы упростить такие приложения, как Plymouth, которым не нужно использовать специальные ускоренные операции, обеспечиваемые специфичными для драйвера ioctl. [134] Эта функция была предоставлена libdrm начиная с версии 2.4.25. [135] Позже в том же году он также получил новый основной тип объектов, названный самолетами . Плоскости были разработаны для представления аппаратных наложений, поддерживаемых механизмом сканирования. [136] [137] Поддержка плоскостей была добавлена в Linux 3.3. [138] и libdrm 2.4.30. Еще одна концепция, добавленная к API - в выпусках Linux 3.5 [139] и libdrm 2.4.36 [140] - это общие свойства объекта , метод добавления общих значений к любому объекту KMS. Свойства особенно полезны для установки особого поведения или функций для таких объектов, как CRTC и плоскости.
Раннее доказательство концепции, обеспечивающей разгрузку графического процессора между драйверами DRM, было разработано Дэйвом Эрли в 2010 году. [7] [141] Поскольку Эйрли пытался имитировать технологию NVIDIA Optimus , он решил назвать ее «PRIME». [7] Эйрли возобновил свою работу над PRIME в конце 2011 года, но на основе нового механизма совместного использования буфера DMA-BUF , представленного ядром Linux 3.3. [142] Базовая инфраструктура DMA-BUF PRIME была завершена в марте 2012 года [143] и объединена с выпуском Linux 3.4, [144] [145] [146], а также с libdrm 2.4.34. [147] Позже, во время выпуска Linux 3.5, несколько драйверов DRM реализовали поддержку PRIME, включая i915 для карт Intel, radeon для карт AMD и nouveau для карт NVIDIA. [148] [149]
В последние годы API DRM постепенно расширялся новыми и улучшенными функциями. В 2013 году в рамках GSoC Дэвид Херрманн разработал функцию множественных узлов рендеринга . [53] Его код был добавлен в ядро Linux версии 3.12 в качестве экспериментальной функции [150] [151], поддерживаемой драйверами i915, [152] radeon [153] и nouveau [154] , и включенной по умолчанию, начиная с Linux 3.17. [75] В 2014 году Мэтт Ропер (Intel) разработал концепцию универсальных плоскостей (или унифицированных плоскостей ), согласно которой буферы кадра ( первичные плоскости ), наложения ( вторичные плоскости ) и курсоры ( плоскости курсора ) рассматриваются как один тип объекта с единый API. [155] Поддержка универсальных плоскостей обеспечивает более согласованный API DRM с меньшим количеством общих ioctl . [33] Чтобы поддерживать обратную совместимость API , эта функция предоставляется ядром DRM как дополнительная возможность, которую может предоставить драйвер DRM. Поддержка универсального уровня дебютировала в Linux 3.15 [156] и libdrm 2.4.55. [157] Несколько драйверов, например Intel i915, [158] уже реализовали это.
Самым последним усовершенствованием DRM API является атомарный API установки режима , который привносит атомарность в операции установки режима и перелистывания страниц на устройстве DRM. Идея атомарного API для настройки режима была впервые предложена в начале 2012 года. [159] Вилле Сюрьяля (Intel) взял на себя задачу разработки и реализации такого атомарного API. [160] Основываясь на своей работе, Роб Кларк ( Texas Instruments ) использовал аналогичный подход, стремясь реализовать атомарные перелистывания страниц. [161] Позже в 2013 году обе предлагаемые функции были объединены в одну с использованием одного ioctl для обеих задач. [162] Поскольку это было обязательным требованием, функция должна была дождаться объединения поддержки универсальных самолетов в середине 2014 года. [158] Во второй половине 2014 года атомарный код был значительно улучшен Дэниелом Веттером (Intel) и другими разработчиками DRM [163] : 18 , чтобы облегчить переход существующих драйверов KMS на новую атомарную структуру. [164] Вся эта работа была наконец объединена в выпусках Linux 3.19 [165] и Linux 4.0 [166] [167] [168] и включена по умолчанию, начиная с Linux 4.2. [169] libdrm представила новый атомарный API, начиная с версии 2.4.62. [170] Несколько драйверов уже преобразованы в новый атомарный API. [171] К 2018 году десять новых драйверов DRM, основанных на этой новой атомарной модели, были добавлены в ядро Linux. [172]
Принятие
Подсистема ядра Direct Rendering Manager изначально была разработана для использования с новой инфраструктурой Direct Rendering для сервера отображения XFree86 4.0, позже унаследованной его преемником, сервером X.Org . Следовательно, основными пользователями DRM были клиенты DRI, которые связываются с аппаратно-ускоренной реализацией OpenGL, которая находится в библиотеке Mesa 3D , а также с самим X-сервером. В настоящее время DRM также используется несколькими композиторами Wayland , включая эталонный композитор Weston . kmscon - это реализация виртуальной консоли, которая запускается в пользовательском пространстве с использованием средств DRM KMS. [173]
В 2015 году версия 358.09 (бета) проприетарного драйвера Nvidia GeForce получила поддержку интерфейса настройки режима DRM, реализованного в виде нового большого двоичного объекта ядра nvidia-modeset.ko
. Этот новый компонент драйвера работает вместе с nvidia.ko
модулем ядра для программирования механизма отображения (то есть контроллера дисплея) графического процессора. [174]
Смотрите также
- Инфраструктура прямого рендеринга
- Бесплатный драйвер графического устройства с открытым исходным кодом
- Фреймбуфер Linux
Рекомендации
- ^ "Ядро Linux / драйверы / gpu / drm / README.drm" . kernel.org . Архивировано из оригинала на 2014-02-26 . Проверено 26 февраля 2014 .
- ^ а б Uytterhoeven, Geert. «Устройство кадровой буферизации» . Kernel.org . Проверено 28 января 2015 года .
- ^ а б в Белый, Томас. «Как работают DRI и DRM» . Проверено 22 июля 2014 года .
- ^ Вера, Рикард Э. (11 мая 1999 г.). «Менеджер прямого рендеринга: поддержка ядра для инфраструктуры прямого рендеринга» . Дата обращения 12 мая 2016 .
- ^ Б с д е е г ч Корбет, Джонатан (6 ноября 2007 г.). «Управление памятью для графических процессоров» . LWN.net . Проверено 23 июля 2014 года .
- ^ Б с д е е г Паккард, Кейт; Анхольт, Эрик (13 мая 2008 г.). «GEM - Менеджер исполнения графики» . Список рассылки Dri-devel . Проверено 23 июля 2014 года .
- ^ а б в Эйрли, Дэйв (12 марта 2010 г.). «Разгрузка GPU - PRIME - доказательство концепции» . Архивировано из оригинального 10 февраля 2015 года . Проверено 10 февраля 2015 года .
- ^ а б в г д Китчинг, Саймон. «Модули ядра DRM и KMS» . Дата обращения 13 мая 2016 .
- ^ а б в г д Херрманн, Дэвид (1 сентября 2013 г.). «Разделение узлов устройств DRM и KMS» . Проверено 23 июля 2014 года .
- ^ «README.rst - mesa / drm - Заголовки и модули ядра Direct Rendering Manager» . 2020-03-21. Архивировано из оригинала на 2020-03-21.
- ^ а б Эйрли, Дэйв (4 сентября 2004 г.). «Предлагаемый новый дизайн интерфейса DRM» . Dri-devel (Список рассылки).
- ^ Б с д е е г Перес, Мартин; Равье, Тимоти (2 февраля 2013 г.). «DRI-next / DRM2: обзор стека графики Linux и его безопасности» (PDF) . Дата обращения 13 мая 2016 .
- ^ Хогсберг, Кристиан (4 сентября 2008 г.). «Расширение DRI2 - версия 2.0» . X.Org . Дата обращения 23 мая 2016 .
- ^ а б в г д е Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Ваннер, Лукас. «Руководство разработчика драйвера графического процессора Linux - Управление памятью» . Проверено 31 августа 2016 года .
- ^ Веттер, Дэниел. "i915 / GEM Crashcourse Даниэля Веттера" . Центр технологий открытого исходного кода Intel . Проверено 31 января 2015 года .
GEM в основном имеет дело с объектами графического буфера (которые могут содержать текстуры, буферы рендеринга, шейдеры или все виды других объектов состояния и данных, используемых графическим процессором)
- ^ а б в Веттер, Дэниел (4 мая 2011 г.). «Обзор GEM» . Проверено 13 февраля 2015 года .
- ^ Паккард, Кит (28 сентября 2012 г.). «Мысли о DRI.Next» . Проверено 26 мая 2016 .
У GEM flink много проблем. Имена флинков являются глобальными, что позволяет любому, у кого есть доступ к устройству, получить доступ к содержимому данных флинков.
- ^ а б Херрманн, Дэвид (2 июля 2013 г.). «Безопасность DRM» . Материалы конференции разработчиков X.Org 2013 (XDC2013) . Проверено 13 февраля 2015 года .
gem-flink не предоставляет никаких частных пространств имен приложениям и серверам. Вместо этого для каждого узла DRM предоставляется только одно глобальное пространство имен. Вредоносные приложения, прошедшие проверку подлинности, могут атаковать других клиентов путем подбора имен буферов гемов методом перебора.
- ^ Керриск, Майкл (25 сентября 2012 г.). «XDC2012: Безопасность графического стека» . LWN.net . Проверено 25 ноября 2015 года .
- ^ а б Паккард, Кит (4 июля 2008 г.). "обновление драгоценного камня" . Проверено 25 апреля 2016 года .
- ^ "Справочная страница drm-memory" . Руководства по Ubuntu . Проверено 29 января 2015 .
Многие современные высокопроизводительные графические процессоры поставляются со своими собственными менеджерами памяти. Они даже включают в себя несколько разных кешей, которые необходимо синхронизировать во время доступа. [...]. Следовательно, управление памятью на графических процессорах сильно зависит от драйверов и оборудования.
- ^ «Руководство разработчика Intel Graphics Media Accelerator» . Корпорация Intel . Проверено 24 ноября 2015 года .
- ^ а б в Ларабель, Майкл (26 августа 2008 г.). «Менеджер TTM на основе GEM для Radeon» . Фороникс . Проверено 24 апреля 2016 года .
- ^ а б в Корбет, Джонатан (28 мая 2008 г.). "GEM против TTM" . LWN.net . Проверено 10 февраля 2015 года .
- ^ Корбет, Джонатан (11 января 2012 г.). «Совместное использование буфера DMA в 3.3» . LWN.net . Дата обращения 14 мая 2016 .
- ^ Кларк, Роб; Семвал, Сумит. «Структура совместного использования буфера DMA: Введение» (PDF) . Дата обращения 14 мая 2016 .
- ^ Перес, Мартин (26 сентября 2014 г.). «Графический стек Linux, Оптимус и драйвер Nouveau» (PDF) . Дата обращения 14 мая 2016 .
- ^ Пинчарт, Лоран (20 февраля 2013 г.). «Анатомия встроенного драйвера KMS» (PDF) . Проверено 27 июня +2016 .
- ^ Эдж, Джейк (9 октября 2013 г.). «DRI3 и настоящее» . LWN.net . Проверено 28 мая 2016 .
- ^ а б в г «Linux 2.6.29 - Настройка ядра» . Новички в ядре Linux . Проверено 19 ноября 2015 года .
- ^ «Аппаратное обеспечение VGA» . OSDev.org . Проверено 23 ноября 2015 года .
- ^ Ратманн, Б. (15 февраля 2008 г.). «Состояние модерна, часть I» . LWN.net . Проверено 23 ноября 2015 года .
Видеокарты программируются множеством способов, но большая часть инициализации и настройки режима выполняется через ввод-вывод с отображением памяти. Это просто набор регистров, доступных ЦП через его стандартное адресное пространство памяти. Регистры в этом адресном пространстве разделены на диапазоны, связанные с различными функциями видеокарты, такими как настройка режима, управление выводом или конфигурация часов.
- ^ а б в г д Пааланен, Пекка (5 июня 2014 г.). «От предыстории к глобальной термоядерной войне» . Проверено 29 июля 2014 года .
- ^ "страница руководства drm-kms" . Руководства по Ubuntu . Проверено 19 ноября 2015 года .
- ^ Корбет, Джонатан (13 января 2010 г.). "Конец настройки режима пользовательского пространства?" . LWN.net . Проверено 20 ноября 2015 года .
- ^ а б "Обсуждение дизайна настроек режима" . X.Org Wiki . Проверено 19 ноября 2015 года .
- ^ а б Корбет, Джонатан (22 января 2007 г.). «LCA: обновления в системе X Window» . LWN.net . Проверено 23 ноября 2015 года .
- ^ "Страница руководства XF86VIDMODE" . X.Org . Проверено 23 апреля 2016 года .
- ^ «Примечания к выпуску X11R6.1» . X.Org . 14 марта 1996 . Проверено 23 апреля 2016 года .
- ^ Корбет, Джонатан (20 июля 2004 г.). «Саммит ядра: видеодрайверы» . LWN.net . Проверено 23 ноября 2015 года .
- ^ а б «Fedora - Возможности / KernelModeSetting» . Проект Fedora . Проверено 20 ноября 2015 года .
Исторически сложилось так, что X-сервер отвечал за сохранение состояния вывода при запуске, а затем за его восстановление при переключении обратно в текстовый режим. Быстрое переключение пользователей было выполнено с помощью переключателя VT, поэтому при переключении с X-сервера первого пользователя будет мигать один раз, чтобы перейти в текстовый режим, а затем сразу же снова мигать, чтобы перейти к сеансу второго пользователя.
- ^ а б в г д Барнс, Джесси (17 мая 2007 г.). «[RFC] улучшение графической подсистемы ядра» . linux-kernel (список рассылки).
- ^ а б в «DrmModesetting - Улучшение графики ядра» . DRI Wiki . Проверено 23 ноября 2015 года .
- ^ а б в г д Паккард, Кит (16 сентября 2007 г.). "драйверы режима ядра" . Проверено 30 апреля 2016 года .
- ^ а б Паккард, Кит (24 апреля 2000 г.). «Повышение внимания к драйверам Intel» . Дата обращения 23 мая 2016 .
Более тонкое ограничение заключается в том, что драйвер не может обрабатывать прерывания, поэтому не было поддержки монитора с возможностью горячей замены.
- ^ Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Ваннер, Лукас. «Руководство разработчика драйвера графического процессора Linux - инициализация драйвера» . Проверено 31 августа 2016 года .
- ^ Б с д е е г Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Ваннер, Лукас. «Руководство разработчика драйвера графического процессора Linux - Инициализация и очистка KMS» . Проверено 31 августа 2016 года .
- ^ а б «Видеокарты» . X.Org Wiki . Проверено 11 апреля +2016 .
- ^ а б Дюшер, Алекс (15 апреля 2010 г.). «Замечания по поводу аппаратного обеспечения дисплея Radeon» . Архивировано из оригинала 5 апреля 2016 года . Проверено 8 апреля 2016 года .
- ^ а б в г д Веттер, Дэниел (5 августа 2015 г.). «Обзор дизайна настройки атомарного режима, часть 1» . LWN.net . Дата обращения 7 мая 2016 .
- ^ а б Рединг, Тьерри (1 февраля 2015 г.). «Установка атомарного режима» (PDF) . Архивы FOSDEM . Дата обращения 7 мая 2016 .
- ^ Веттер, Дэниел (12 августа 2015 г.). «Обзор дизайна настройки атомарного режима, часть 2» . LWN.net . Дата обращения 7 мая 2016 .
- ^ а б в Херрманн, Дэвид (29 мая 2013 г.). "Узлы рендеринга и режима DRM" . Проверено 21 июля 2014 года .
- ^ а б в г Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Ваннер, Лукас. «Руководство разработчика драйвера графического процессора Linux - узлы рендеринга» . Проверено 31 августа 2016 года .
- ^ а б Дюшер, Алекс (20 апреля 2015 г.). «Первоначальный выпуск драйвера amdgpu» . Dri-devel (Список рассылки).
- ^ а б «Linux 2.6.33 - Nouveau, драйвер для видеокарт Nvidia» . Новички в ядре Linux . Проверено 26 апреля 2016 года .
- ^ а б «drm / nouveau: добавить драйвер DRM для графических процессоров NVIDIA» . Kernel.org . Проверено 27 января 2015 года .
- ^ «DRM: добавить драйвер DRM для Samsung SoC EXYNOS4210» . Kernel.org . Проверено 3 марта +2016 .
- ^ «vmwgfx: исключить драйвер из постановки» . Kernel.org . Проверено 3 марта +2016 .
- ^ «Linux 3.3 - DriverArch - Графика» . Новички в ядре Linux . Проверено 3 марта +2016 .
- ^ Ларабель, Майкл (10 января 2012 г.). «Потребление DRM в Linux 3.3 требует усовершенствований» . Фороникс . Проверено 3 марта +2016 .
- ^ «drm: начальный драйвер KMS для AST (ASpeed Technologies) серии 2000 (v2)» . Kernel.org . Проверено 3 марта +2016 .
- ^ Эйрли, Дэйв (17 мая 2012 г.). «mgag200: начальный драйвер g200se (v2)» . Проверено 24 января 2018 .
- ^ «DRM: драйвер Renesas SH Mobile DRM» . Kernel.org . Проверено 3 марта +2016 .
- ^ «drm: Добавить поддержку NVIDIA Tegra20» . Kernel.org . Проверено 3 марта +2016 .
- ^ "drm / omap: выйти из постановки" . Kernel.org . Проверено 3 марта +2016 .
- ^ «drm: Драйвер DRM Renesas R-Car Display Unit» . Kernel.org . Проверено 3 марта +2016 .
- ^ «drm / msm: базовый драйвер KMS для Snapdragon» . Kernel.org . Проверено 3 марта +2016 .
- ^ Ларабель, Майкл (28 августа 2013 г.). «Слияние драйвера Snapdragon DRM / KMS для Linux 3.12» . Фороникс . Проверено 26 января 2015 года .
- ^ Эдж, Джейк (8 апреля 2015 г.). «Обновление графического драйвера freedreno» . LWN.net . Проверено 23 апреля 2015 года .
- ^ Кинг, Рассел (18 октября 2013 г.). «[GIT PULL] Поддержка Armada DRM» . Dri-devel (Список рассылки).
- ^ «DRM: Armada: добавить драйвер Armada DRM» . Kernel.org . Проверено 3 марта +2016 .
- ^ «drm / bochs: новый драйвер» . Kernel.org . Проверено 3 марта +2016 .
- ^ Ларабель, Майкл (8 августа 2014 г.). «Linux 3.17 DRM Pull приносит новый графический драйвер» . Фороникс . Проверено 3 марта +2016 .
- ^ а б Корбет, Джонатан (13 августа 2014 г.). «3.17 окно слияния, часть 2» . LWN.net . Проверено 7 октября 2014 года .
- ^ а б Корбет, Джонатан (17 декабря 2014 г.). «3.19 Окно слияния, часть 2» . LWN.net . Дата обращения 9 февраля 2015 .
- ^ «drm: imx: переместить драйвер imx-drm из постановки» . Kernel.org . Дата обращения 9 февраля 2015 .
- ^ «drm: rockchip: Добавить базовый драйвер drm» . Kernel.org . Проверено 3 марта +2016 .
- ^ Ларабель, Майкл (25 июня 2015 г.). «Обновления DRM Linux 4.2: большое внимание AMD, никаких новых изменений драйверов» . Фороникс . Проверено 31 августа 2015 года .
- ^ Корбет, Джонатан (1 июля 2015 г.). «4.2 Окно слияния, часть 2» . LWN.net . Проверено 31 августа 2015 года .
- ^ Дюшер, Алекс (3 августа 2015 г.). «[PATCH 00/11] Добавить поддержку Фиджи» . Dri-devel (Список рассылки).
- ^ «Добавить драйвер virtio gpu» . Kernel.org . Проверено 3 марта +2016 .
- ^ Корбет, Джонатан (11 ноября 2015 г.). «4.4 Окно слияния, часть 1» . LWN.net . Проверено 11 января +2016 .
- ^ Ларабель, Майкл (15 ноября 2015 г.). «Взгляд на новые возможности ядра Linux 4.4» . Фороникс . Проверено 11 января +2016 .
- ^ «drm / vc4: добавить поддержку KMS для Raspberry Pi» . Kernel.org .
- ^ Ларабель, Майкл (24 января 2016 г.). «Множество новых функций и улучшений ядра Linux 4.5» . Фороникс . Проверено 14 марта 2016 .
- ^ Корбет, Джонатан (20 января 2016 г.). «4.5 окно слияния, часть 2» . LWN.Net . Проверено 14 марта 2016 .
- ^ «Слить тег 'sun4i-drm-for-4.7 ' » . Kernel.org .
- ^ а б в Эйрли, Дэйв (23 мая 2016 г.). "[git pull] drm для v4.7" . Dri-devel (Список рассылки).
- ^ «Слить тег 'drm-hisilicon-next-2016-04-29 ' » . Kernel.org .
- ^ «Слить тег 'mediatek-drm-2016-05-09 ' » . Kernel.org .
- ^ Ларабель, Майкл (22 ноября 2016 г.). «Драйвер Hisilicon Hibmc DRM добавляется для Linux 4.10» . Фороникс . Проверено 24 января 2018 .
- ^ «Технический документ Huawei FusionServer RH5885 V3» . 18 ноября 2016 года Архивировано из оригинала на 2018-01-25.
использует встроенную микросхему дисплея, которая интегрирована в микросхему управления Hi1710 и использует IP-ядро SM750
- ^ «постановка: vboxvideo: добавить vboxvideo в драйверы / постановку» . git.kernel.org . Проверено 2 марта 2021 .
- ^ Ларабель, Майкл (9 июня 2017 г.). «Графический драйвер VirtualBox DRM / KMS готовится к работе с основным ядром» . Фороникс . Проверено 2 марта 2021 года .
- ^ "kernel / git / torvalds / linux.git - дерево исходных текстов ядра Linux" . git.kernel.org . Проверено 28 ноября 2019 .
- ^ "kernel / git / torvalds / linux.git - дерево исходных текстов ядра Linux" . git.kernel.org . Проверено 28 ноября 2019 .
- ^ "drm: удалить драйвер гаммы" . Kernel.org . Проверено 27 января 2015 года .
- ^ «[DRM]: Удалите код драйвера sparc64 FFB, который никогда не собирается» . Kernel.org . Проверено 27 января 2015 года .
- ^ «drm: удалить драйвер i830» . Kernel.org . Проверено 27 января 2015 года .
- ^ "drm: Добавить через поддержку unichrome" . Kernel.org . Проверено 27 января 2015 года .
- ^ "drm: добавить дикого водителя" . Kernel.org . Проверено 27 января 2015 года .
- ^ «Список разработчиков ядра Linux» . Kernel.org . Проверено 14 июля 2014 года .
- ^ "репозиторий libdrm git" . Проверено 23 июля 2014 года .
- ^ «Первый выпуск DRI драйвера 3dfx» . Меса 3D . Проверено 15 июля 2014 года .
- ^ «Импорт 2.3.18pre1» . История Linux в формате репозитория GIT 1992-2010 (2010) . Проверено 15 июля 2014 года .
- ^ Торвальдс, Линус. «Исходный код Linux 2.4.0» . Kernel.org . Проверено 29 июля 2014 года .
- ^ Эйрли, Дэйв (30 декабря 2004 г.). «[bk pull] drm core / индивидуальный раскол» . linux-kernel (список рассылки).
- ^ Торвальдс, Линус (11 января 2005 г.). «Linux 2.6.11-rc1» . linux-kernel (список рассылки).
- ^ Геттис, Джеймс; Паккард, Кит (15 июня 2004 г.). «(Ре) Архитектура системы X Window» . Проверено 30 апреля 2016 года .
- ^ Смирл, Джон (30 августа 2005 г.). «Состояние графики Linux» . Проверено 30 апреля 2016 года .
Я считаю, что лучшим решением этой проблемы является предоставление ядром единого комплексного драйвера устройства для каждой части видеооборудования. Это означает, что конфликтующие драйверы, такие как fbdev и DRM, должны быть объединены в взаимодействующую систему. Это также означает, что следует предотвратить извлечение оборудования из пользовательского пространства во время загрузки драйвера устройства на основе ядра.
- ^ Верхаген, Люк (2 марта 2006 г.). «X и Modesetting: иллюстрированная атрофия» (PDF) . Проверено 30 апреля 2016 года .
- ^ Глисс, Джером (4 декабря 2007 г.). «Настройка режима ядра Radeon» . Проверено 30 апреля 2016 года .
- ^ Ларабель, Майкл (1 октября 2008 г.). «Состояние настройки режима ядра» . Фороникс . Проверено 30 апреля 2016 года .
- ^ Паккард, Кит (21 июля 2008 г.). «Состояние вывода X июль 2008 г.» . Дата обращения 1 мая 2016 .
- ^ «DRM: реорганизуйте дерево DRM, чтобы оно было более надежным в будущем» . Kernel.org .
- ^ «Linux 2.6.28 - Менеджер памяти GEM для памяти GPU» . Новички в ядре Linux . Проверено 23 июля 2014 года .
- ^ «drm: добавить подсистему диспетчера памяти графического процессора TTM» . Kernel.org .
- ^ «DRM: поддержка настройки режима добавления» . Kernel.org .
- ^ «DRM: i915: поддержка настройки режима добавления» . Kernel.org .
- ^ Анхольт, Эрик (22 декабря 2008 г.). "[ОБЪЯВЛЕНИЕ] libdrm-2.4.3" . Dri-devel (Список рассылки).
- ^ Барнс, Джесси (20 октября 2008 г.). «[ОБЪЯВЛЕНИЕ] xf86-video-intel 2.5.0» . xorg-announce (Список рассылки).
- ^ «Linux 2.6.31 - Поддержка режима ядра ATI Radeon» . Новички в ядре Linux . Архивировано из оригинала 5 ноября 2015 года . Проверено 28 апреля 2016 года .
- ^ Торвальдс, Линус (9 сентября 2009 г.). «Linux 2.6.31» . linux-kernel (список рассылки).
- ^ "drm / radeon: ввести настройки режима ядра для оборудования radeon" . Kernel.org .
- ^ "Необычный спутник развития модерна №40" . Модерн-проект . Дата обращения 3 мая 2016 .
- ^ «Linux 2.6.33 - Графические улучшения» . Новички в ядре Linux . Проверено 28 апреля 2016 года .
- ^ "drm / kms: добавить страницу перелистывающего ioctl" . Kernel.org .
- ^ «Linux 2.6.38 - Графика» . Новички в ядре Linux . Проверено 28 апреля 2016 года .
- ^ Эйрли, Дэйв (21 декабря 2009 г.). «[ОБЪЯВЛЕНИЕ] libdrm 2.4.17» . Dri-devel (Список рассылки).
- ^ "drm: dumb scanout create / mmap для intel / radeon (v3)" . Kernel.org .
- ^ «Linux 2 6 39-DriversArch» . Новички в ядре Linux . Проверено 19 апреля 2016 года .
- ^ Барнс, Джесси; Пинчарт, Лоран; Веттер, Дэниел; Ваннер, Лукас. «Руководство разработчика драйвера графического процессора Linux - немые буферные объекты» . Проверено 31 августа 2016 года .
- ^ Уилсон, Крис (11 апреля 2011 г.). "[ОБЪЯВЛЕНИЕ] libdrm 2.4.25" . Dri-devel (Список рассылки).
- ^ Барнс, Джесси (25 апреля 2011 г.). «[RFC] drm: добавление оверлеев как первоклассных объектов KMS» . Dri-devel (Список рассылки).
- ^ Барнс, Джесси (13 мая 2011 г.). «[RFC] drm: добавление оверлеев как первоклассных объектов KMS» . Dri-devel (Список рассылки).
- ^ "drm: добавить поддержку самолетов v3" . Kernel.org .
- ^ «drm: добавить общие ioctls для получения / установки свойств любого объекта» . Kernel.org .
- ^ Видавски, Бен (27 июня 2012 г.). "[ОБЪЯВЛЕНИЕ] libdrm 2.4.36" . xorg-announce (Список рассылки).
- ^ Ларабель, Майкл. "Proof Of Concept: Open-Source Multi-GPU Rendering!" . Фороникс . Проверено 14 апреля 2016 года .
- ^ Ларабель, Майкл (23 февраля 2012 г.). «Поддержка DRM Base PRIME как часть работы VGEM» . Фороникс . Проверено 14 апреля 2016 года .
- ^ Эйрли, Дэйв (27 марта 2012 г.). «[PATCH] drm: поддержка базового прайма / dma-buf (v5)» . Dri-devel (Список рассылки).
- ^ Ларабель, Майкл (30 марта 2012 г.). «Последняя минута для Linux 3.4: Поддержка DMA-BUF PRIME» . Фороникс . Проверено 15 апреля 2016 года .
- ^ "drm: поддержка базового прайма / dma-buf (v5)" . Kernel.org .
- ^ «Linux 3.4 DriverArch» . Новички в ядре Linux . Проверено 15 апреля 2016 года .
- ^ Анхольт, Эрик (10 мая 2012 г.). "[ОБЪЯВЛЕНИЕ] libdrm 2.4.34" . Dri-devel (Список рассылки).
- ^ Ларабель, Майкл (12 мая 2012 г.). «DMA-BUF PRIME объединяется для Linux 3.5» . Фороникс . Проверено 15 апреля 2016 года .
- ^ «Linux 3.5 DriverArch» . Новички в ядре Linux . Проверено 15 апреля 2016 года .
- ^ Корбет, Джонатан (11 сентября 2013 г.). «3.12 окно слияния, часть 2» . LWN.net . Проверено 21 июля 2014 года .
- ^ "drm: реализовать экспериментальные узлы рендеринга" . Kernel.org .
- ^ «drm / i915: Поддержка узлов рендеринга» . Kernel.org .
- ^ "drm / radeon: Поддержка узлов рендеринга" . Kernel.org .
- ^ "drm / nouveau: Поддержка узлов рендеринга" . Kernel.org .
- ^ Ропер, Мэтт (7 марта 2014 г.). «[RFCv2 00/10] Поддержка универсальных плоскостей» . Dri-devel (Список рассылки).
- ^ Ларабель, Майкл (2 апреля 2014 г.). «Универсальный набор поддержки плоскости для Linux 3.15» . Фороникс . Проверено 14 апреля 2016 года .
- ^ Ланкхорст, Маартен (25 июля 2014 г.). "[ОБЪЯВЛЕНИЕ] libdrm 2.4.55" . Dri-devel (Список рассылки).
- ^ а б Веттер, Дэниел (7 августа 2014 г.). «Штучка за 3,17» . Проверено 14 апреля 2016 года .
- ^ Барнс, Джесси (15 февраля 2012 г.). "[RFC] drm: API установки атомарного режима" . Dri-devel (Список рассылки).
- ^ Сюряля, Вилле (24 мая 2012 г.). «[RFC] [PATCH 0/6] WIP: drm: идея настройки атомарного режима» . Dri-devel (Список рассылки).
- ^ Кларк, Роб (9 сентября 2012 г.). "[RFC 0/9] ядерный переворот страницы" . Dri-devel (Список рассылки).
- ^ Кларк, Роб (6 октября 2013 г.). "[RFCv1 00/12] Атомный / ядерный режим / переворот страницы" . Dri-devel (Список рассылки).
- ^ Веттер, Дэниел (3 февраля 2016 г.). «Примите эпоху атомных дисплеев» (PDF) . Дата обращения 4 мая 2016 .
- ^ Веттер, Дэниел (2 ноября 2014 г.). «Поддержка Atomic Modeset для драйверов KMS» . Дата обращения 4 мая 2016 .
- ^ Эйрли, Дэйв (14 декабря 2014 г.). "[git pull] drm для 3.19-rc1" . Dri-devel (Список рассылки).
- ^ Веттер, Дэниел (28 января 2015 г.). «Обновление для обновлений атомарного дисплея» . Дата обращения 4 мая 2016 .
- ^ Эйрли, Дэйв (15 февраля 2015 г.). "[git pull] drm pull для 3.20-rc1" . Dri-devel (Список рассылки).
- ^ «Linux 4.0 - DriverArch - Графика» . Новички в ядре Linux . Дата обращения 3 мая 2016 .
- ^ «Linux 4.2 - API настройки атомарного режима включен по умолчанию» . Новички в ядре Linux . Дата обращения 3 мая 2016 .
- ^ Великов, Эмиль (29 июня 2015 г.). "[ОБЪЯВЛЕНИЕ] libdrm 2.4.62" . Dri-devel (Список рассылки).
- ^ Веттер, Дэниел (6 июня 2016 г.). «Потрясающие достижения в атомной сфере» . Проверено 7 июня +2016 .
прямо сейчас есть 17 драйверов, поддерживающих атомарную настройку режимов, объединенных в подсистему DRM
- ^ Стоун, Дэниел (20 марта 2018 г.). «Новая эра низкоуровневой графики Linux - Часть 1» . Проверено 5 мая 2018 .
- ^ Херрманн, Дэвид (10 декабря 2012 г.). «Введение в KMSCON» . Проверено 22 ноября 2015 года .
- ^ «Драйвер 358.09 для Linux, Solaris и FreeBSD (бета)» . 2015-12-10.
Внешние ссылки
- Домашняя страница DRM
- Руководство разработчика драйвера графического процессора Linux (ранее - Руководство разработчика DRM для Linux )
- Embedded Linux Conference 2013 - Анатомия встроенного драйвера KMS на YouTube