Введение
Реализация DRI разбросана по X Server и связанным с ним клиентским библиотекам, Mesa 3D и подсистеме ядра Direct Rendering Manager. Клиент DRI — например, X-клиент, выполняющий "прямой рендеринг" — нуждается в аппаратно-специфичном "драйвере", способном управлять текущей видеокартой или графическим адаптером для осуществления рендеринга. Эти драйверы DRI обычно предоставляются в виде динамически подключаемых библиотек, к которым клиент подключается во время выполнения. Поскольку DRI был разработан для использования преимуществ 3D-графического оборудования, библиотеки обычно представляются клиентам как аппаратно ускоренные реализации 3D API, таких как OpenGL, предоставляемые либо производителем 3D-оборудования, либо сторонними разработчиками, такими как проект свободного программного обеспечения Mesa 3D. X Server предоставляет расширение протокола X11 — расширение DRI — которое клиенты DRI используют для координации как с оконной системой, так и с драйвером DDX. В рамках драйвера DDX часто встречается ситуация, когда процесс X Server также динамически подключается к тому же драйверу DRI, что и DRI-клиенты, но для обеспечения аппаратного ускорения 3D-рендеринга для X-клиентов с использованием расширения GLX для непрямого рендеринга (например, для удаленных X-клиентов, которые не могут использовать прямой рендеринг). Для 2D-рендеринга драйвер DDX также должен учитывать клиентов DRI, использующих то же графическое устройство. Доступ к видеокарте или графическому адаптеру регулируется компонентом ядра под названием Direct Rendering Manager (DRM). И драйвер DDX X Server, и драйвер DRI каждого X-клиента должны использовать DRM для доступа к графическому оборудованию. DRM обеспечивает синхронизацию общих ресурсов графического оборудования — таких как очередь команд, регистры карты, видеопамять, DMA-движки, — гарантируя, что одновременный доступ множества конкурирующих процессов пользовательского пространства не приводит к конфликтам. DRM также выполняет роль базового механизма безопасности, не позволяя любому X-клиенту получить доступ к оборудованию сверх необходимого для выполнения 3D-рендеринга.
DRI implementation is scattered through the X Server and its associated client libraries, Mesa 3D and the Direct Rendering Manager kernel subsystem. the DRI client —for example, an X client performing "direct rendering"— needs a hardware specific "driver" able to manage the current video card or graphics adapter in order to render on it. These DRI drivers are typically provided as shared libraries to which the client is dynamically linked. Since DRI was conceived to take advantage of 3D graphics hardware, the libraries are normally presented to clients as hardware accelerated implementations of a 3D API such as OpenGL, provided by either the 3D hardware vendor itself or a third party such as the Mesa 3D free software project. the X Server provides an X11 protocol extension —the DRI extension— that the DRI clients use to coordinate with both the windowing system and the DDX driver. As part of the DDX driver, it's quite common that the X Server process also dynamically links to the same DRI driver that the DRI clients, but to provide hardware accelerated 3D rendering to the X clients using the GLX extension for indirect rendering (for example remote X clients that can't use direct rendering). For 2D rendering, the DDX driver must also take into account the DRI clients using the same graphics device. the access to the video card or graphics adapter is regulated by a kernel component called the Direct Rendering Manager (DRM). Both the X Server's DDX driver and each X client's DRI driver must use DRM to access to the graphics hardware. DRM provides synchronization to the shared resources of the graphics hardware —resources such as the command queue, the card registers, the video memory, the DMA engines, — ensuring that the concurrent access of all those multiple competing user space processes don't interfere with each other. DRM also serves as a basic security enforcer that doesn't allow any X client to access the hardware beyond what it needs to perform the 3D rendering.
DRI1
В оригинальной архитектуре DRI, из-за ограниченного размера памяти видеокарт того времени, существовал единственный экземпляр переднего и заднего буферов экрана (а также вспомогательного буфера глубины и буфера трафарета), совместно используемый всеми клиентами DRI и сервером X. Окончательным решением стало изменение способа обработки буферов рендеринга в DRI, что привело к созданию совершенно нового расширения DRI с новым набором операций и значительным изменениям в Direct Rendering Manager. Впервые оно стало широко доступно в составе XFree86 4.0 и теперь является частью сервера X.Org. В настоящее время его сопровождает сообщество свободного программного обеспечения. Работа над DRI2 началась на саммите разработчиков X 2007 года по предложению Кристиана Хёгсберга. Сам Хёгсберг разработал новое расширение DRI2 и внес изменения в Mesa и GLX. В марте 2008 года DRI2 был практически завершен, но не был включен в версию X.Org Server 1.5 и пришлось ждать выхода версии 1.6 в феврале 2009 года. Расширение DRI2 было официально включено в релиз X11R7.5 в октябре 2009 года. Первая публичная версия протокола DRI2 (2.0) была анонсирована в апреле 2009 года. С тех пор было несколько редакций, самой последней из которых является версия 2.8, выпущенная в июле 2012 года. В связи с рядом ограничений DRI2, на конференции разработчиков X.Org в 2012 году Кейт Паккард и Эмма Анхолт предложили новое расширение под названием DRI Next. Первая и единственная версия протокола DRI3 (1.0) была выпущена в ноябре 2013 года.