provide any synchronization with the vertical blanking interval, so it can cause tearing. , on the other hand, performs a VBLANK-synchronized swap between back and front buffer, if it's supported and both buffers have the same size, or a copy (blit) otherwise. DRI3 Although DRI2 was a significant improvement over the original DRI, the new extension also introduced some new issues. In 2013, a third iteration of the Direct Rendering Infrastructure known as DRI3 was developed in order to fix those issues. The main differences of DRI3 compared to DRI2 are: DRI3 clients allocate themselves their render buffers instead of relying on the X Server for doing the allocation —that was the method supported by DRI2. DRI3 gets rid of the old insecure GEM buffer sharing mechanism based on GEM names (global GEM handles) for passing buffer objects between a DRI client and the X Server in favor of the one more secure and versatile based on PRIME DMA-BUFs, which uses file descriptors instead. Buffer allocation on the client side breaks GLX assumptions in the sense that it's no longer possible for multiple GLX applications to render cooperatively in the same window. On the plus side, the fact that the DRI client is in charge of its own buffers throughout their lifetime brings many advantages. For example, it is easy for the DRI3 client to ensure that the size of the render buffers always match the current size of the window, and thereby eliminate the artifacts due to the lack of synchronization of buffer sizes between client and server that plagued window resizing in DRI2. A better performance is also achieved because now DRI3 clients save the extra round trip waiting for the X Server to send the render buffers. DRI3 clients, and especially compositor window managers, can take advantage of keeping older buffers of previous frames and reusing them as the basis on which to render only the damaged parts of a window as another performance optimization. The DRI3 extension no longer needs to be modified to support new particular buffer formats, since they are now handled directly between the DRI client driver and the DRM kernel driver. The use of file descriptors, on the other hand, allows the kernel to perform a safe cleanup of any unused GEM buffer object —one with no reference to it. Technically, DRI3 consists of two different extensions, the "DRI3" extension and the