✖


Jump to content

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

(Перенаправлено с DRI2 )
ДРИ-1.0
Оригинальный автор(ы) Precision Insight, вольфрамовая графика
Разработчик(и) freedesktop.org
Первоначальный выпуск август 1998 г .; 26 лет назад ( 1998-08 ) [ 1 ]
Стабильная версия
2.4.х / февраль 2009 г.
Написано в С
Платформа ПОСИКС
Тип Фреймворк / API
Лицензия MIT и другие лицензии [ 2 ]
Веб-сайт дри .freedesktop .org
ДРИ-2.0
Оригинальный автор(ы) Кристиан Хёгсберг и др.
Разработчик(и) freedesktop.org
Первоначальный выпуск 4 сентября 2008 г .; 15 лет назад ( 04.09.2008 ) [ 3 ]
Стабильная версия
2,8 / 11 июля 2012 г .; 12 лет назад ( 11.07.2012 ) [ 4 ]
Написано в С
Платформа ПОСИКС
Тип Фреймворк / API
Лицензия MIT и другие лицензии [ 2 ]
Веб-сайт дри .freedesktop .org
ДРИ-3.0
Оригинальный автор(ы) Кейт Паккард и др.
Разработчик(и) freedesktop.org
Первоначальный выпуск 1 ноября 2013 г .; 10 лет назад ( 01.11.2013 ) [ 5 ]
Стабильная версия
1.0 / 1 ноября 2013 г .; 10 лет назад ( 01.11.2013 ) [ 5 ]
Написано в С
Платформа ПОСИКС
Тип Фреймворк / API
Лицензия MIT и другие лицензии [ 2 ]
Веб-сайт дри .freedesktop .org
Существует два драйвера графического оборудования: один находится внутри X- дисплея сервера . Было несколько конструкций этого драйвера. Текущая версия разделяет его на две части: DIX (независимый от устройства X) и DDX (зависимый от устройства X).
Glamour упростит X-сервер , и libGL-fglrx-glx [ нужно обновить ] можно использовать libDRM драйвера с открытым исходным кодом Radeon вместо проприетарного двоичного объекта .
Расчеты рендеринга передаются через OpenGL на графический процессор и выполняются в режиме реального времени. DRI . регулирует доступ и ведение бухгалтерского учета

Инфраструктура прямого рендеринга ( DRI ) — это платформа, включающая современный графический стек Linux , которая позволяет непривилегированным программам пользовательского пространства выдавать команды графическому оборудованию, не конфликтуя с другими программами. [ 6 ] Основное использование DRI — обеспечение аппаратного ускорения в Mesa реализации OpenGL . DRI также был адаптирован для обеспечения ускорения OpenGL на консоли кадрового буфера без работающего сервера отображения . [ 7 ]

Реализация DRI разбросана по X-серверу и связанным с ним клиентским библиотекам, Mesa 3D и подсистеме ядра Direct Rendering Manager . [ 6 ] Весь исходный код является свободным программным обеспечением .

Обзор

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

В классической архитектуре X Window System X-сервер является единственным процессом, имеющим эксклюзивный доступ к графическому оборудованию , и, следовательно, именно он выполняет фактическую визуализацию в кадровом буфере . Все, что делают X-клиенты, — это общаются с X-сервером для отправки команд рендеринга. Эти команды не зависят от оборудования, а это означает, что протокол X11 предоставляет API , который абстрагирует графическое устройство, поэтому клиентам X не нужно знать или беспокоиться о специфике базового оборудования. Любой аппаратно-зависимый код находится внутри Device Dependent 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-оборудования, либо третьей стороной, такой как Mesa 3D. проект бесплатного программного обеспечения .
  • X-сервер предоставляет расширение протокола X11 — расширение DRI, которое клиенты DRI используют для координации как с оконной системой , так и с драйвером DDX. [ 9 ] Как часть драйвера DDX, процесс X-сервера часто динамически связывается с тем же драйвером DRI, что и клиенты DRI, но для обеспечения аппаратного ускорения 3D-рендеринга для X-клиентов с использованием расширения GLX для непрямого рендеринга (для например, удаленные X-клиенты, которые не могут использовать прямой рендеринг). Для 2D-рендеринга драйвер DDX также должен учитывать клиенты DRI, использующие то же графическое устройство.
  • доступ к видеокарте или графическому адаптеру регулируется компонентом ядра, называемым Direct Rendering Manager (DRM). [ 10 ] Драйвер DDX X-сервера и драйвер DRI каждого X-клиента должны использовать DRM для доступа к графическому оборудованию. DRM обеспечивает синхронизацию с общими ресурсами графического оборудования — такими ресурсами, как очередь команд, регистры карт, видеопамять, механизмы DMA и т. д. — гарантируя, что одновременный доступ ко всем этим многочисленным конкурирующим процессам в пользовательском пространстве невозможен. Мешайте друг другу. DRM также служит базовым средством обеспечения безопасности, которое не позволяет никакому X-клиенту получить доступ к оборудованию сверх того, что ему необходимо для выполнения 3D-рендеринга.

ДРИ1

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

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

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

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

ДРИ2

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

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

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

Чтобы обрабатывать все эти новые буферы, Диспетчеру прямого рендеринга пришлось включить новую функциональность, в частности, диспетчер графической памяти . DRI2 изначально был разработан с использованием экспериментального менеджера памяти TTM . [ 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 ( DRI2Аутентификация ). [ 3 ] Представление отрендеренных буферов на экране осуществляется с помощью DRI2CopyRegion и Запросы DRI2SwapBuffers . DRI2CopyRegion можно использовать для копирования между поддельным передним буфером и реальным передним буфером, но он не обеспечивает никакой синхронизации с интервалом вертикального гашения, поэтому может вызвать разрыв . DRI2SwapBuffers , с другой стороны, выполняет синхронизированную по VBLANK замену между задним и передним буфером, если это поддерживается и оба буфера имеют одинаковый размер, или копию ( blit ) в противном случае. [ 3 ] [ 15 ]

ДРИ3

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

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

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

Распределение буфера на стороне клиента нарушает предположения GLX в том смысле, что несколько приложений GLX больше не могут совместно выполнять рендеринг в одном окне. С другой стороны, тот факт, что клиент DRI отвечает за свои собственные буферы на протяжении всего их срока службы, дает много преимуществ. Например, клиенту DRI3 легко гарантировать, что размер буферов рендеринга всегда соответствует текущему размеру окна, и тем самым устранить артефакты из-за отсутствия синхронизации размеров буфера между клиентом и сервером, которые мешают изменению размера окна. в ДРИ2. [ 15 ] [ 16 ] [ 18 ] Повышенная производительность также достигается за счет того, что теперь клиенты DRI3 экономят дополнительное время ожидания, пока X-сервер отправит буферы рендеринга. [ 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, называемого «растровое изображение». 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 не предоставляет механизма для отображения отображаемых буферов на экране, но Present . для этого использует другое расширение, расширение [ 20 ] Present назван так потому, что его основная задача — «представить» буферы на экране, то есть он обрабатывает обновление кадрового буфера, используя содержимое визуализированных буферов, доставленных клиентскими приложениями. [ 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-клиентам две основные операции: обновить область окна, используя часть или все содержимое растрового изображения ( PresentPixmap ) и задайте тип событий презентации, относящихся к определенному окну, о котором клиент хочет получать уведомления ( PresentSelectInput ). [ 19 ] [ 21 ] Существует три события представления, о которых окно может уведомить X-клиента: когда текущая операция представления — обычно от вызова PresentPixmap — завершено ( PresentCompleteNotify ), когда растровое изображение, используемое Операция PresentPixmap готова к повторному использованию ( PresentIdleNotify ) и при изменении конфигурации окна (в основном размера окна) ( PresentConfigureNotify ). [ 19 ] [ 21 ] Будь то Операция PresentPixmap выполняет прямую копию ( блит ) в передний буфер или замену всего заднего буфера на передний буфер — это внутренняя деталь реализации расширения Present, вместо явного выбора X-клиента, как это было в DRI2.

Принятие

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

Было написано несколько драйверов DRI с открытым исходным кодом, в том числе для ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3–Voodoo5, Matrox G200–G400, серии SiS 300, Intel i810–i965, S3 Savage, VIA графических чипсетов UniChrome и нуво для Nvidia . Некоторые поставщики графических систем написали драйверы DRI с закрытым исходным кодом, включая ATI и PowerVR Kyro.

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

История

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

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

Работа над DRI2 началась на X Саммите разработчиков 2007 года по предложению Кристиана Хёгсберга . [ 24 ] [ 25 ] Сам Хёгсберг написал новое расширение DRI2 и модификации Mesa и GLX . [ 26 ] В марте 2008 года DRI2 в основном был завершен. [ 27 ] [ 28 ] [ 29 ] но он не смог войти в версию X.Org Server версии 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 году и объединены в версию X.Org Server 1.15 в декабре 2013 года. [ 33 ] [ 34 ] Первая и единственная версия протокола DRI3 (1.0) была выпущена в ноябре 2013 года. [ 5 ]

См. также

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

Ссылки

[ редактировать ]
  1. ^ Jump up to: а б с Оуэн, Йенс. «История проекта DRI» . Вики-проект проекта DRI . Проверено 16 апреля 2016 г.
  2. ^ Jump up to: а б с Лицензия Mesa DRI / Информация об авторских правах — Библиотека 3D-графики Mesa
  3. ^ Jump up to: а б с д и ж Хёгсберг, Кристиан (4 сентября 2008 г.). «Расширение DRI2 – Версия 2.0» . X.Орг . Проверено 29 мая 2016 г.
  4. ^ Jump up to: а б Эйрли, Дэйв (11 июля 2012 г.). «[АНОНС] dri2proto 2.8» . xorg-announce (список рассылки).
  5. ^ Jump up to: а б с Паккард, Кейт (1 ноября 2013 г.). «[АНОНС] dri3proto 1.0» . xorg-announce (список рассылки).
  6. ^ Jump up to: а б «Вики-сайт Mesa 3D и инфраструктуры прямого рендеринга» . Проверено 15 июля 2014 г.
  7. ^ «DRI для консолей фреймбуфера» . Проверено 4 января 2019 г.
  8. ^ Мартин, Кевин Э.; Вера, Рикард Э.; Оуэн, Йенс; Акин, Аллен (11 мая 1999 г.). «Инфраструктура прямого рендеринга, низкоуровневый проектный документ» . Проверено 18 мая 2016 г.
  9. ^ Оуэн, Йенс; Мартин, Кевин (11 мая 1999 г.). «Расширение DRI для поддержки прямого рендеринга — спецификация протокола» . Проверено 18 мая 2016 г.
  10. ^ Фейт, Рикард Э. (11 мая 1999 г.). «Диспетчер прямого рендеринга: поддержка ядра для инфраструктуры прямого рендеринга» . Проверено 18 мая 2016 г.
  11. ^ Jump up to: а б с д и ж Паккард, Кейт (21 июля 2008 г.). «Статус выхода X июль 2008 г.» . Проверено 26 мая 2016 г.
  12. ^ Jump up to: а б с д и ж г Паккард, Кейт (24 апреля 2009 г.). «Усиление внимания драйверов Intel» . Проверено 26 мая 2016 г.
  13. ^ Jump up to: а б Хёгсберг, Кристиан (8 августа 2007 г.). «Перенаправленный прямой рендеринг» . Проверено 25 мая 2016 г.
  14. ^ Jump up to: а б Хёгсберг, Кристиан (4 августа 2008 г.). «Откат DRI2 с сервера 1.5» . xorg (список рассылки).
  15. ^ Jump up to: а б с д и ж г час я дж к л Паккард, Кейт (28 сентября 2012 г.). «Мысли о ДРИ.Next» . Проверено 26 мая 2016 г.
  16. ^ Jump up to: а б с д и ж г час я дж Уиллис, Натан (11 февраля 2013 г.). «LCA: Люди Икс говорят» . LWN.net . Проверено 26 мая 2016 г.
  17. ^ Jump up to: а б с Паккард, Кейт (19 февраля 2013 г.). «DRI3000 — еще лучший прямой рендеринг» . Проверено 26 мая 2016 г.
  18. ^ Jump up to: а б с д и ж Паккард, Кейт (4 июня 2013 г.). «Завершение расширения DRI3» . Проверено 31 мая 2016 г.
  19. ^ Jump up to: а б с д и ж г час я дж Эдж, Джейк (9 октября 2013 г.). «ДРИ3 и настоящее время» . LWN.net . Проверено 26 мая 2016 г.
  20. ^ Jump up to: а б с Паккард, Кейт (4 июня 2013 г.). «Расширение DRI3 — версия 1.0» . Проверено 30 мая 2016 г. .
  21. ^ Jump up to: а б с д Паккард, Кейт (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.Орг . Проверено 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» . Проверено 20 апреля 2016 г.
  30. ^ «Ветка Сервера 1.6» . Х.орг . Проверено 7 февраля 2015 г.
  31. ^ «Примечания к выпуску X11R7.5» . X.Орг . Проверено 20 апреля 2016 г.
  32. ^ Хёгсберг, Кристиан (20 апреля 2009 г.). dri2proto "[ОБЪЯВЛЕНИЕ ] xorg-announce (список рассылки).
  33. ^ Паккард, Кейт (ноябрь 2013 г.). «[ОБЪЯВЛЕНИЕ] xorg-сервер 1.14.99.901» . Х.орг . Проверено 9 февраля 2015 г.
  34. ^ Ларабель, Майкл. «Выпуск X.Org Server 1.15 имеет несколько новых функций» . Фороникс . Проверено 9 февраля 2015 г.
[ редактировать ]
Викискладе есть медиафайлы, связанные с инфраструктурой прямого рендеринга .
Retrieved from "https://en.wikipedia.org/w/index.php?title=Direct_Rendering_Infrastructure&oldid=1238868564"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: ba7005ed50368d0533295f64151c1fc6__1722903600
URL1:https://arc.ask3.ru/arc/aa/ba/c6/ba7005ed50368d0533295f64151c1fc6.html
Заголовок, (Title) документа по адресу, URL1:
Direct Rendering Infrastructure - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)