WikiDer > Инфраструктура прямого рендеринга

Direct Rendering Infrastructure
DRI-1.0
Оригинальный автор (ы)Precision Insight, графика из вольфрама
Разработчики)freedesktop.org
изначальный выпускАвгуст 1998 г.; 22 года назад (1998-08)[1]
Стабильный выпуск
2.4.x / февраль 2009 г.
Написано вC
ПлатформаPOSIX
ТипРамки / API
ЛицензияМассачусетский технологический институт и другие лицензии[2]
Интернет сайтдри.freedesktop.org
DRI-2.0
Оригинальный автор (ы)Кристиан Хегсберг и другие.
Разработчики)freedesktop.org
изначальный выпуск4 сентября 2008 г.; 12 лет назад (2008-09-04)[3]
Стабильный выпуск
2.8 / 11 июля 2012 г.; 8 лет назад (2012-07-11)[4]
Написано вC
ПлатформаPOSIX
ТипРамки / API
ЛицензияМассачусетский технологический институт и другие лицензии[2]
Интернет сайтдри.freedesktop.org
DRI-3.0
Оригинальный автор (ы)Кейт Паккард и другие.
Разработчики)freedesktop.org
изначальный выпуск1 ноября 2013; 7 лет назад (2013-11-01)[5]
Стабильный выпуск
1.0 / 1 ноября 2013 г.; 7 лет назад (2013-11-01)[5]
Написано вC
ПлатформаPOSIX
ТипРамки / API
ЛицензияМассачусетский технологический институт и другие лицензии[2]
Интернет сайтдри.freedesktop.org
Есть два драйвера графического оборудования: один находится внутри X сервер отображения. Было несколько разработок этого драйвера. Текущий разделит его на две части: DIX (Device-Independent X) и DDX (Device-Dependent X)
Гламур упростит X сервер, и libGL-fglrx-glx может использовать libDRM драйвера с открытым исходным кодом radeon вместо проприетарного двоичный blob.
Рендеринг расчеты переданы на аутсорсинг OpenGL к GPU делать в режиме реального времени. В DRI регулирует доступ и бухгалтерский учет.

В Инфраструктура прямого рендеринга (DRI) - это структура для обеспечения прямого доступа к графическое оборудование под X Window System безопасным и эффективным способом.[6] Основное использование DRI - обеспечение аппаратного ускорения для Меса реализация OpenGL. DRI также был адаптирован для обеспечения ускорения OpenGL на консоль кадрового буфера без сервер отображения Бег.[7]

Реализация DRI разбросана по X сервер и связанные с ним клиентские библиотеки, Меса 3D и Менеджер прямого рендеринга подсистема ядра.[6] Все его исходный код является бесплатно программное обеспечение.

Обзор

В классике X Window System архитектура X Server - единственный процесс с монопольным доступом к графическое оборудование, и, следовательно, тот, который действительно рендеринг на кадровый буфер. Все, что делают X-клиенты, - это общаются с X-сервером для отправки команд рендеринга. Эти команды не зависят от оборудования, а это означает, что X11 протокол обеспечивает API который абстрагирует графическое устройство, поэтому X-клиентам не нужно знать или беспокоиться о специфике базового оборудования. Любой код, специфичный для оборудования, живет внутри Зависит от устройства X, часть X-сервера, которая управляет каждым типом видеокарты или графического адаптера и которую также часто называют видео или же графический драйвер.

Подъем 3D рендеринг показал пределы этой архитектуры. Приложения для 3D-графики имеют тенденцию генерировать большие объемы команд и данных, которые все должны быть отправлены на X-сервер для рендеринга. Как количество межпроцессного взаимодействия (IPC) между X-клиентом и X-сервером увеличилась, производительность 3D-рендеринга снизилась до такой степени, что разработчики X-драйвера пришли к выводу, что для использования преимуществ аппаратных возможностей 3D новейших видеокарт требуется новая архитектура без IPC. Клиенты X должны иметь прямой доступ к графическому оборудованию, а не полагаться в этом на сторонний процесс, что позволяет снизить накладные расходы IPC. Этот подход называется «прямым рендерингом» в отличие от «косвенного рендеринга», обеспечиваемого классической архитектурой X. В Инфраструктура прямого рендеринга изначально был разработан, чтобы позволить любому X-клиенту выполнять 3D-рендеринг с использованием этого подхода «прямого рендеринга».

Ничто не мешает использовать DRI для реализации ускоренного прямого 2D-рендеринга в X-клиенте.[3] Просто никому в этом не было необходимости, потому что производительность косвенного 2D-рендеринга была достаточно хорошей.

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

Базовая архитектура инфраструктуры прямого рендеринга включает три основных компонента:[8]

  • клиенту DRI - клиенту X, выполняющему «прямой рендеринг», необходим аппаратно-зависимый «драйвер», способный управлять текущей видеокартой или графическим адаптером для рендеринга на нем. Эти Драйверы DRI обычно предоставляются как общие библиотеки к которому клиент динамически связанный. Поскольку DRI был задуман для использования преимуществ оборудования 3D-графики, библиотеки обычно представляются клиентам как аппаратно ускоренные реализации 3D API, такие как OpenGL, предоставляемые либо самим поставщиком 3D-оборудования, либо третьей стороной, например Меса 3D бесплатно программное обеспечение проект.
  • X-сервер предоставляет Расширение протокола X11 - расширение DRI - которое клиенты DRI используют для координации с обоими оконная система и драйвер DDX.[9] Как часть драйвера DDX, довольно часто процесс X-сервера также динамически связывается с тем же драйвером DRI, что и клиенты DRI, но для обеспечения аппаратного ускорения 3D-рендеринга X-клиентам с использованием GLX расширение для косвенного рендеринга (например, удаленные X-клиенты, которые не могут использовать прямой рендеринг). Для 2D-рендеринга драйвер DDX также должен учитывать клиентов DRI, использующих то же графическое устройство.
  • доступ к видеокарте или графическому адаптеру регулируется компонентом ядра, называемым Менеджер прямого рендеринга (DRM).[10] И драйвер DDX сервера X, и драйвер DRI каждого клиента X должны использовать DRM для доступа к графическому оборудованию. DRM обеспечивает синхронизация к общим ресурсам графического оборудования - таким ресурсам, как очередь команд, регистры карты, видеопамять, механизмы DMA, ... - гарантируя, что одновременный доступ всех этих нескольких конкурирующих процессов пользовательского пространства не мешает работе друг друга. DRM также служит основным средством обеспечения безопасности, которое не позволяет любому X-клиенту получать доступ к оборудованию сверх того, что ему необходимо для выполнения 3D-рендеринга.

DRI1

В исходной архитектуре DRI из-за размера памяти видеокарты в то время был единственный экземпляр экрана передний буфер и задний буфер (также из вспомогательных буфер глубины и трафаретный буфер), совместно используемый всеми клиентами DRI и X-сервером.[11][12] Все они рендерились прямо в задний буфер, то есть поменяны местами с передним буфером на интервал вертикального гашения время.[11] Чтобы выполнить рендеринг в задний буфер, процесс DRI должен гарантировать, что рендеринг был обрезанный в область, отведенную под его окно.[11][12]

В синхронизация с X-сервером было сделано через сигналы и Общая память буфер называется SAREA.[12] Доступ к устройству DRM был монопольным, поэтому любой клиент DRI должен был замок это в начале рендеринг операция. Тем временем другие пользователи устройства, включая X-сервер, были заблокированы, и им приходилось ждать, пока блокировка не будет снята в конце текущей операции визуализации, даже если это не приведет к конфликту между обеими операциями.[12] Еще одним недостатком было то, что операции не сохраняли выделение памяти после того, как текущий процесс DRI снял блокировку на устройстве, поэтому любые данные, загруженные в графическую память, например текстуры были потеряны для предстоящих операций, что оказало значительное влияние на производительность графики.

В настоящее время DRI1 считается полностью устаревшим и не может использоваться.

DRI2

В связи с растущей популярностью композитинг оконных менеджеров подобно Compizинфраструктуру прямого рендеринга пришлось переработать, чтобы клиенты X могли также поддерживать перенаправление на «закадровые пиксельные изображения» при выполнении прямого рендеринга. Обычные X-клиенты уже соблюдали перенаправление на отдельное растровое изображение, предоставленное X-сервером в качестве цели рендеринга - так называемое закадровое растровое изображение - но клиенты DRI продолжали выполнять рендеринг непосредственно в общий задний буфер, эффективно обходя оконный менеджер композитинга.[11][13] Конечным решением было изменить способ обработки буферов рендеринга DRI, что привело к совершенно другому расширению DRI с новым набором операций, а также к серьезным изменениям в системе. Менеджер прямого рендеринга.[3] Новое расширение было названо «DRI2», хотя это не более поздняя версия, а другое расширение, даже несовместимое с исходным DRI - фактически оба сосуществовали в X Server в течение долгого времени.

В DRI2 вместо одного разделяемого (заднего) буфера каждый DRI-клиент получает свой собственный частный буфер. задний буфер[11][12] - наряду с их связанными глубина и трафарет буферы - для рендеринга окно контент с использованием аппаратное ускорение. Затем клиент DRI свопы это с ложным "передний буфер",[12] который используется оконным менеджером композитинга в качестве одного из источников для составления (построения) последнего обратного буфера экрана, который должен быть заменен на Интервал VBLANK с настоящим передним буфером.

Чтобы обрабатывать все эти новые буферы, Direct Rendering Manager должен был включить новые функции, в частности графику. менеджер памяти. DRI2 изначально был разработан с использованием экспериментального ТТМ менеджер памяти,[11][13] но позже он был переписан для использования GEM после того, как он был выбран в качестве окончательного менеджера памяти DRM.[14] Новая модель управления внутренним буфером DRI2 также решила два основных узких места производительности, присутствовавших в исходной реализации DRI:

  • Клиенты DRI2 больше не блокируют все устройство DRM при использовании его для рендеринга, поскольку теперь каждый клиент получает отдельный буфер рендеринга, независимый от других процессов.[12]
  • Клиенты DRI2 могут выделять свои собственные буферы (с текстурами, списками вершин и т. Д.) В видеопамяти и хранить их столько, сколько захотят, что значительно уменьшает видео. пропускная способность памяти потребление.

В DRI2 выделение частных закадровых буферов (задний буфер, поддельный передний буфер, буфер глубины, буфер шаблона и т. Д.) Для окна выполняется самим X-сервером.[15][16] Клиенты DRI извлекают эти буферы, чтобы выполнить рендеринг в окно, вызывая такие операции, как DRI2GetBuffers и DRI2GetBuffersWithFormat доступно в расширении DRI2.[3] Внутренне DRI2 использует Имена GEM - тип глобального дескриптора, предоставляемый GEM API который позволяет двум процессам, обращающимся к DRM-устройству, обращаться к одному и тому же буферу - для передачи «ссылок» на эти буферы через X11 протокол.[16] Причина, по которой X-сервер отвечает за распределение буферов для буферов рендеринга окна, заключается в том, что Расширение GLX позволяет нескольким X-клиентам делать OpenGL рендеринг совместно в одном окне.[15] Таким образом, X-сервер управляет всем жизненным циклом буферов рендеринга на протяжении всего процесса рендеринга и знает, когда он может безопасно их переработать или отбросить. Когда выполняется изменение размера окна, X-сервер также отвечает за выделение новых буферов рендеринга, соответствующих новому размеру окна, и уведомление об изменении рендеринга клиента (-ов) DRI в окно с помощью события InvalidateBuffers, чтобы они могли получить GEM имена новых буферов.[15]

Расширение DRI2 обеспечивает другие основные операции для клиентов DRI, такие как определение устройства DRM и драйвера, которые они должны использовать (DRI2Connect) или пройти аутентификацию X-сервером, чтобы иметь возможность использовать средства визуализации и буферизации устройства DRM (DRI2Authenticate).[3] Отображение визуализированных буферов на экране выполняется с помощью DRI2CopyRegion и DRI2SwapBuffers Запросы. DRI2CopyRegion может использоваться для копирования между фальшивым передним буфером и реальным передним буфером, но он не обеспечивает никакой синхронизации с интервалом вертикального гашения, поэтому может вызвать разрывание. DRI2SwapBuffers, с другой стороны, выполняет обмен с синхронизацией VBLANK между задним и передним буферами, если он поддерживается и оба буфера имеют одинаковый размер, или копию (бред) иначе.[3][15]

DRI3

Хотя DRI2 был значительным улучшением по сравнению с исходным DRI, новое расширение также внесло некоторые новые проблемы.[15][16] В 2013 году была разработана третья итерация инфраструктуры прямого рендеринга, известная как DRI3, для устранения этих проблем.[17]

Основные отличия DRI3 от DRI2:

  • Клиенты DRI3 выделяют свои буферы рендеринга вместо того, чтобы полагаться на X-сервер для выполнения распределения - это был метод, поддерживаемый DRI2.[15][16]
  • DRI3 избавляется от старых небезопасных GEM механизм совместного использования буфера на основе Имена GEM (глобальные дескрипторы GEM) для передачи буферных объектов между DRI-клиентом и X-сервером в пользу более безопасного и универсального, основанного на PRIME DMA-BUFs, который использует файловые дескрипторы вместо.[15][16]

Распределение буфера на стороне клиента разрывается GLX Предположения в том смысле, что для нескольких приложений GLX больше невозможно совместное рендеринг в одном окне. С другой стороны, тот факт, что клиент DRI отвечает за свои буферы на протяжении всего их срока службы, дает много преимуществ. Например, для клиента DRI3 легко гарантировать, что размер буферов рендеринга всегда соответствует текущему размеру окна, и тем самым устранить артефакты из-за отсутствия синхронизации размеров буфера между клиентом и сервером, которые мешали изменению размера окна. в DRI2.[15][16][18] Лучшая производительность также достигается благодаря тому, что теперь клиенты DRI3 экономят дополнительный круговой обход, ожидая, пока X Server отправит буферы рендеринга.[16] Клиенты DRI3, и особенно оконные менеджеры композитора, могут воспользоваться преимуществами сохранения старых буферов предыдущих кадров и их повторного использования в качестве основы для визуализации только поврежденных частей окна в качестве еще одной оптимизации производительности.[15][16] Расширение DRI3 больше не нужно модифицировать для поддержки новых конкретных форматов буферов, поскольку теперь они обрабатываются непосредственно между драйвером клиента DRI и драйвером ядра DRM.[15] С другой стороны, использование файловых дескрипторов позволяет ядру выполнять безопасную очистку любого неиспользуемого буферного объекта GEM - любого, без ссылки на него.[15][16]

Технически DRI3 состоит из двух разных расширений: расширения DRI3 и расширения Present.[17][19] Основная цель расширения DRI3 - реализовать механизм совместного использования буферов прямого рендеринга между клиентами DRI и X-сервером.[18][19][20] Клиенты DRI выделяют и используют объекты буферов GEM в качестве целей рендеринга, в то время как X-сервер представляет эти буферы рендеринга с помощью типа объекта X11, называемого «pixmap». DRI3 обеспечивает две операции: DRI3PixmapFromBuffer и DRI3BufferFromPixmapодин для создания растрового изображения (в «пространстве X-сервера») из буферного объекта GEM (в «DRI-клиентском пространстве»), а другой - для выполнения обратного действия и получения буферного объекта GEM из X-растрового изображения.[18][19][20] В этих операциях DRI3 буферные объекты GEM передаются как DMA-BUF дескрипторы файлов вместо имен GEM. DRI3 также предоставляет способ совместного использования объектов синхронизации между DRI-клиентом и X-сервером, обеспечивая как сериализованный доступ к совместно используемому буферу.[19] В отличие от DRI2, начальная DRI3Open операция - сначала каждый клиент DRI должен запросить, какое устройство DRM использовать - возвращает уже открытый дескриптор файла на узел устройства вместо имени файла узла устройства, при этом любая требуемая процедура аутентификации уже выполнена заранее X-сервером.[18][19]

DRI3 не предоставляет механизма для отображения визуализированных буферов на экране, но полагается на другое расширение, Подарок расширение, чтобы сделать это.[20] Подарок назван так потому, что его основная задача - «представить» буферы на экране, что означает, что он обрабатывает обновление кадрового буфера, используя содержимое визуализированных буферов, доставленных клиентскими приложениями.[19] Обновления экрана должны выполняться в надлежащее время, обычно во время Интервал VBLANK во избежание артефактов отображения, таких как разрывание. Present также обрабатывает синхронизацию обновлений экрана с интервалом VBLANK.[21] Он также информирует X-клиента о моменте, когда каждый буфер действительно отображается на экране с помощью событий, поэтому клиент может синхронизировать свой процесс рендеринга с текущей частотой обновления экрана.

Present принимает любое растровое изображение X в качестве источника для обновления экрана.[21] Поскольку растровые изображения являются стандартными объектами X, Present может использоваться не только клиентами DRI3, выполняющими прямой рендеринг, но также и любым рендерингом клиента X на растровом изображении любыми средствами.[18] Например, большинство существующих не-GL основан GTK + и Qt приложения, используемые для с двойной буферизацией рендеринг растровых изображений с использованием XRender. Расширение Present также может использоваться этими приложениями для обеспечения эффективных обновлений экрана без разрывов. По этой причине Present был разработан как отдельное автономное расширение, а не как часть DRI3.[18]

Помимо возможности синхронизации клиентов, отличных от GL X, с VBLANK, Present имеет и другие преимущества. Графическая производительность DRI3 лучше, потому что Present более эффективен, чем DRI2 при подкачке буферов.[19] Ряд расширений OpenGL, которые не были доступны в DRI2, теперь поддерживаются на основе новых функций, предоставляемых Present.[19]

Present предоставляет X-клиентам две основные операции: обновление области окна с использованием части или всего содержимого растрового изображения (Присутствует) и установить тип событий презентации, связанных с определенным окном, о котором клиент хочет получать уведомления (PresentSelectInput).[19][21] Есть три события презентации, о которых окно может уведомить X-клиента: когда текущая операция презентации - обычно от вызова к Присутствует- завершено (PresentCompleteNotify), когда растровое изображение, используемое Присутствует операция готова к повторному использованию (PresentIdleNotify) и когда конфигурация окна - в основном размер окна - изменяется (PresentConfigureNotify).[19][21] Будь Присутствует операция выполняет прямое копирование (бред) на передний буфер или замена всего заднего буфера с передним буфером - это внутренняя деталь реализации расширения Present, а не явный выбор X-клиента, как это было в DRI2.

Принятие

Было написано несколько драйверов DRI с открытым исходным кодом, в том числе для ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 через Voodoo5, Matrox От G200 до G400, SiS серии 300, Intel с i810 по i965, S3 Дикий, ЧЕРЕЗ Графические чипсеты UniChrome и модерн за Nvidia. Некоторые поставщики графики написали драйверы DRI с закрытым исходным кодом, включая ATI и Киро.

Различные версии DRI были реализованы различными операционными системами, в том числе Ядро Linux, FreeBSD, NetBSD, OpenBSD, и OpenSolaris.

История

Проект был начат Йенсом Оуэном и Кевином Э. Мартином из компании Precision Insight (финансируется Силиконовая Графика и Красная шляпа).[1][22] Впервые он был широко доступен как часть XFree86 4.0[1][23] и теперь является частью Сервер X.Org. В настоящее время поддерживается сообщество свободного программного обеспечения.

Работа над DRI2 началась в 2007 году на X Developers 'Summit с Кристиан Хегсбергпредложение.[24][25] Сам Хогсберг написал новое расширение DRI2 и модификации для Меса и GLX.[26] В марте 2008 года DRI2 в основном был завершен,[27][28][29] но это не могло превратиться в Сервер X.Org версия 1.5[14] и пришлось ждать до версии 1.6 от февраля 2009 года.[30] Расширение DRI2 было официально включено в выпуск X11R7.5 от октября 2009 года.[31] Первая публичная версия протокола DRI2 (2.0) была анонсирована в апреле 2009 года.[32] С тех пор было внесено несколько изменений, последняя из которых - версия 2.8 от июля 2012 года.[4]

Из-за некоторых ограничений DRI2 новое расширение под названием DRI-Next было предложено Кейт Паккард и Эрик Анхольт на конференции разработчиков X.Org в 2012 году.[15] Расширение было снова предложено как DRI3000 на Linux.conf.au 2013.[16][17] Расширения DRI3 и Present были разработаны в 2013 году и с декабря 2013 года объединены в выпуск X.Org Server 1.15.[33][34] Первая и единственная версия протокола DRI3 (1.0) была выпущена в ноябре 2013 года.[5]

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

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

  1. ^ а б c Оуэн, Йенс. «История проекта DRI». Вики проекта DRI. Получено 16 апреля 2016.
  2. ^ а б c Лицензия Mesa DRI / Информация об авторских правах - Библиотека 3D-графики Mesa
  3. ^ а б c d е ж Хогсберг, Кристиан (4 сентября 2008 г.). «Расширение DRI2 - версия 2.0». X.Org. Получено 29 мая 2016.
  4. ^ а б Эйрли, Дэйв (11 июля 2012 г.). "[ОБЪЯВЛЕНИЕ] dri2proto 2.8". xorg-анонс (Список рассылки).
  5. ^ а б c Паккард, Кейт (1 ноября 2013 г.). "[ОБЪЯВЛЕНИЕ] dri3proto 1.0". xorg-анонс (Список рассылки).
  6. ^ а б "Вики по инфраструктуре Mesa 3D и Direct Rendering". Получено 15 июля 2014.
  7. ^ «DRI для консолей с кадровым буфером». Получено 4 января, 2019.
  8. ^ Мартин, Кевин Э .; Вера, Рикард Э .; Оуэн, Йенс; Акин, Аллен (11 мая 1999 г.). «Инфраструктура прямого рендеринга, проектный документ нижнего уровня». Получено 18 мая 2016.
  9. ^ Оуэн, Йенс; Мартин, Кевин (11 мая 1999 г.). «Расширение DRI для поддержки прямого рендеринга - спецификация протокола». Получено 18 мая 2016.
  10. ^ Вера, Рикард Э. (11 мая 1999 г.). «Менеджер прямого рендеринга: поддержка ядра для инфраструктуры прямого рендеринга». Получено 18 мая 2016.
  11. ^ а б c d е ж Паккард, Кит (21 июля 2008 г.). «Состояние вывода X июль 2008 г.». Получено 26 мая 2016.
  12. ^ а б c d е ж грамм Паккард, Кейт (24 апреля 2009 г.). «Повышение внимания к драйверам Intel». Получено 26 мая 2016.
  13. ^ а б Хогсберг, Кристиан (8 августа 2007 г.). «Перенаправленный прямой рендеринг». Получено 25 мая 2016.
  14. ^ а б Хогсберг, Кристиан (4 августа 2008 г.). «Резервное копирование DRI2 с сервера 1.5». xorg (Список рассылки).
  15. ^ а б c d е ж грамм час я j k л Паккард, Кейт (28 сентября 2012 г.). «Мысли о DRI.Next». Получено 26 мая 2016.
  16. ^ а б c d е ж грамм час я j Уиллис, Натан (11 февраля 2013 г.). "LCA: Люди Икс говорят". LWN.net. Получено 26 мая 2016.
  17. ^ а б c Паккард, Кит (19 февраля 2013 г.). «DRI3000 - еще лучший прямой рендеринг». Получено 26 мая 2016.
  18. ^ а б c d е ж Паккард, Кейт (4 июня 2013 г.). «Завершение расширения DRI3». Получено 31 мая 2016.
  19. ^ а б c d е ж грамм час я j Эдж, Джейк (9 октября 2013 г.). «DRI3 и настоящее». LWN.net. Получено 26 мая 2016.
  20. ^ а б c Паккард, Кейт (4 июня 2013 г.). «Расширение DRI3 - версия 1.0». Получено 30 мая 2016.
  21. ^ а б c d Паккард, Кит (6 июня 2013 г.). «Настоящее расширение - версия 1.0». Получено 1 июня 2016.
  22. ^ Оуэн, Йенс; Мартин, Кевин Э. (15 сентября 1998 г.). «Многоканальная архитектура прямого рендеринга для 3D». Получено 16 апреля 2016.
  23. ^ «Примечания к выпуску для XFree86 4.0». Проект XFree86. 7 марта 2000 г.. Получено 16 апреля 2016.
  24. ^ «X Саммит разработчиков 2007 - Примечания». X.Org. Получено 7 марта 2016.
  25. ^ Хегсберг, Кристиан (3 октября 2007 г.). "Вики-страница DRI2 Design". xorg (Список рассылки).
  26. ^ Хегсберг, Кристиан (4 февраля 2008 г.). «Планы по объединению DRI2 работают». xorg (Список рассылки).
  27. ^ Хогсберг, Кристиан (15 февраля 2008 г.). "DRI2 совершено". xorg (Список рассылки).
  28. ^ Хогсберг, Кристиан (31 марта 2008 г.). «DRI2 прямой рендеринг». xorg (Список рассылки).
  29. ^ Хогсберг, Кристиан (31 марта 2008 г.). «DRI2 Direct Rendering». Получено 20 апреля 2016.
  30. ^ «Филиал Сервер 1.6». X.org. Получено 7 февраля 2015.
  31. ^ «Примечания к выпуску для X11R7.5». X.Org. Получено 20 апреля 2016.
  32. ^ Хогсберг, Кристиан (20 апреля 2009 г.). "[ОБЪЯВЛЕНИЕ] dri2proto 2.0". xorg-анонс (Список рассылки).
  33. ^ Паккард, Кит. "[ОБЪЯВЛЕНИЕ] xorg-server 1.14.99.901". X.org. Получено 9 февраля 2015.
  34. ^ Ларабель, Майкл. «В выпуске X.Org Server 1.15 есть несколько новых функций». Фороникс. Получено 9 февраля 2015.

внешняя ссылка