If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Nothing. Don't bother. DRI3 is an improvement to a dying technology - next year both Gnome and KDE are scheduled (for serious) to run on Wayland by default and DRI3 is meant for X.Org.

Remember that many applications will keep running with X.

DRI2:
. DDX allocates the buffers for the client, and give them a GEM name to access them
. The client sends his buffer to the Xserver, which will copy it to the front buffer (except if the client is fullscreen and you use vsync. In that case you avoid the copy).

DRI3:
. The client allocates its buffers.
-> it can convert the buffer to a pixmap with a prime fd
-> if can get a prime fd from a pixmap to render to it as a buffer

It isn't sufficient to replace DRI2, that's why there is Present (which can be used also for clients not using DRI3)
Present:
. The client gives a pixmap to the Xserver and gives information to when it should be displayed.
. The client indicates if it want a copy (to the "front" pixmap), or if it accepts the Xserver to keep the buffer (the client will use another buffer in the mean time, and send it, before getting back the old one)
. The client gets back precise information of when the pixmap was displayed.

On a Wayland point of view, Present is close to how Wayland works (except Wayland doesn't have the case for which the client can request its buffer to be copied to the relevant location and get back immediately its buffer).
That makes clients accepting the Xserver to keep the buffer similar to Wayland clients (and Mesa glx accepts the Xserver keeps its buffers).
That gives Wayland flexibility about the ways to support the Present extension, and helps avoiding useless copies in XWayland.

DRI3 uses prime instead of GEM names, then it can be used with render-nodes and is more secure.

Interesting. I remeber that some people said that KDE 4.11 with its KWin improvements finally allowed people with Intel graphics to have tearfree compositing if I'm not mistaken.

I can confirm tear free compositing under KDE 4.11 with Intel HD 4000 on both Fedora 19 and openSUSE 13.1. There is an option in System Settings->Desktop Effects->Advanced tab->Tearing Prevention(VSync)->Full scene repaints.

I can confirm tear free compositing under KDE 4.11 with Intel HD 4000 on both Fedora 19 and openSUSE 13.1. There is an option in System Settings->Desktop Effects->Advanced tab->Tearing Prevention(VSync)->Full scene repaints.

Yeah, the full scene repaints option is a hack to get tear free working. With DRI3 that should no longer be needed, and you should get a nice performance boost compared to having it on.