X协议虽然是间接渲染的代表性协议，但是实际上它也支持直接渲染扩展。和原生的直接渲染协议——wayland相比，x协议和wayland协议的主要差异就是没有把合成器和窗口管理器合二为一了，这也是性能损失最大的地方（合成器和窗口管理器做了很多重复的工作，且多做了很多不需要的正文切换）。
DRI1
由于早期的显卡（video cards）内存大小很小，在最初的dri框架里，DRI client和server共享一个front buffer和back buffer（其实还有其他depth buffer和stencil buffer也只有一个实例）。所有的程序直接将图形渲染到back buffer，然后vb 间隔里和front buffer交换，以完成显示。
和Xserver之间的同步操作是通过信号和一个叫做SAREA的共享内存buffer来实现的。对DRM device的访问是独占的，所以任何DRI client都需要在渲染开始时锁定该设备。这也意味着其他用户，包括Xserver在内，同时刻是被阻塞的。他们只能等到渲染完成后的锁释放时刻。即使两者的操作不会有冲突也必须这样。另外一个缺点就是所有的操作释放锁之后，就不能保留已分配的内存。所以被上传到显存里的纹理数据也会丢失。因此对性能影响很大。
DRI2
由于合成窗口管理器如compiz越来越受欢迎，DRI需要重新设计来满足X 由于合成窗口管理器如compiz（特殊的Xclient）越来越受欢迎，DRI需要重新设计来满足X client在使用直接渲染时也可以进行离线渲染功能。一般情况下X client时满足重定向图形到由X server提供的另外一个pixmap（offscreen pixmap）作为渲染目标，但是DRI client还是只能渲染到共享的backbuffer，这个流程充当了实际的合成管理器，导致compiz等实际的合成管理器无效。终极解决方案时改变DRI处理渲染buffer的方式，这就导致一个完全不同的DRI client如果还是只能渲染到唯一且共享的back buffer，那它实际相当于做了合成管理器的工作，导致compiz这个实际的合成管理器被旁路。终极解决方案时改变DRI处理渲染buffer的方式，这就导致一个完全不同的DRI 扩展——DRI2被设计出来。DRI2不是DRI1的延续，而是另外一个扩展。
在DRI2中，摒弃了只有一个唯一的back 在DRI2中，摒弃了只有一个唯一共享的back buffer的方案，取而代之的是每个DRI client都可以拥有自己的back buffer，这样每个client都可以使用硬件加速渲染将窗口内容。然后client将一个假的front buffer和backbuffer进行交换，这个假的front buffer又是下一个阶段——窗口合成管理器的输入之一。合成窗口管理器将所有的输入合成到最后的back buffer里，在vblank间隔内交换到front buffer。
...
但是在client端分配缓存打破了GLX之前关于多个client共同渲染一个窗口的设计。所以从此多个client无法共同渲染同一个窗口。进一步讲，DRI client管理缓存能有效实现窗口和缓存的尺寸匹配需求，解决了DRI2模式下的问题。还有一个优点是窗口合成管理器（也是一个dri3 client）就可以保留历史的buffer，复用于下一帧的显示，以节省空间。client）就可以保留历史的buffer，复用于下一帧的显示，以节省时间片。
从技术上讲，DRI有两个不同扩展组成，“Present”和“DRI3”。DRI3扩展主要用于共享缓存，client分配缓存作为渲染目标，而xserver使用x11 的object名称pixmap来表示这些缓存。DRI3提供两个操作，DRI3PixmapFromBuffer 和 DRI3BufferFromPixmap，其中一个是通过GEM buffer object（在DRI client 空间）创建pixmap（x server的空间），另外一个是反向操作。从x pixmap获得gem buffer object。在这些操作中，gembuffer object 都通过dmabuf 文件描述符进行传递。不同于DRI2，DRI3open操作，必须在每个driclient第一步被调用，以获取到底用哪个drm device。 它会返回一个关于设备节点的已打开的文件描述符，而不是一个设备节点名。同时也会由Xserver 在高级模式下执行后续需要的认证流程。
...