graphics memory manager. DRI2 was initially developed using the experimental TTM memory manager, but it was later rewritten to use GEM after it was chosen as the definitive DRM memory manager. The new DRI2 internal buffer management model also solved two major performance bottlenecks present in the original DRI implementation: DRI2 clients no longer lock the entire DRM device while using it for rendering, since now each client gets a separate render buffer independent from the other processes. DRI2 clients can allocate their own buffers (with textures, vertex lists, ...) in the video memory and keep them as long as they want, which significantly reduces video memory bandwidth consumption. In DRI2, the allocation of the private offscreen buffers (back buffer, fake front buffer, depth buffer, stencil buffer, ...) for a window is done by the X Server itself. DRI clients retrieve those buffers to do the rendering into the window by calling operations such as and available in the DRI2 extension. Internally, DRI2 uses GEM names —a type of global handle provided by the GEM API that allows two processes accessing a DRM device to refer to the same buffer— for passing around "references" to those buffers through the X11 protocol. The reason why the X Server is in charge of the buffer allocation of the render buffers of a window is that the GLX extension allows for multiple X clients to do OpenGL rendering cooperatively in the same window. This way, the X Server manages the whole lifecycle of the render buffers along the entire rendering process and knows when it can safely recycle or discard them. When a window resize is performed, the X Server is also responsible for allocating new render buffers matching the new window size, and notifying the change to the DRI client(s) rendering into the window using an InvalidateBuffers event, so they would retrieve the GEM names of the new buffers. The DRI2 extension provides other core operations for the DRI clients, such as finding out which DRM device and driver should they use () or getting authenticated by the X Server in order to be able to use the rendering and buffer facilities of the DRM device (). The presentation of the rendered buffers in the screen is performed using the and requests. can be used to do a copy between the fake front buffer and the real front buffer, but it doesn't