Results 1 to 10 of 10

Thread: DRI3 Support Comes For X.Org GLAMOR

  1. #1
    Join Date
    Jan 2007
    Posts
    15,126

    Default DRI3 Support Comes For X.Org GLAMOR

    Phoronix: DRI3 Support Comes To GLAMOR X.Org Driver

    As the first X.Org graphics driver past the open-source Intel driver to have mainline support for Direct Rendering Infrastructure 3 is GLAMOR...

    http://www.phoronix.com/vr.php?view=MTUzNjk

  2. #2
    Join Date
    Jul 2012
    Posts
    799

    Default

    So once these DIR 3000 changes land in the X server and (drivers?) and (toolkits?). What exactly will I notice?

  3. #3
    Join Date
    Feb 2013
    Posts
    88

    Default

    Quote Originally Posted by blackout23 View Post
    So once these DIR 3000 changes land in the X server and (drivers?) and (toolkits?). What exactly will I notice?
    http://www.phoronix.com/scan.php?pag...tem&px=MTE4ODc

  4. #4
    Join Date
    May 2012
    Posts
    866

    Default

    Quote Originally Posted by blackout23 View Post
    So once these DIR 3000 changes land in the X server and (drivers?) and (toolkits?). What exactly will I notice?
    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.

  5. #5
    Join Date
    Dec 2012
    Posts
    158

    Default

    Quote Originally Posted by mark45 View Post
    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.

  6. #6
    Join Date
    Nov 2011
    Posts
    287

    Default

    Quote Originally Posted by blackout23 View Post
    So once these DIR 3000 changes land in the X server and (drivers?) and (toolkits?). What exactly will I notice?
    Tearing on Gnome shell with Intel GPUs is said to be impossible to fix without DRI3 and Mesa 10.
    https://bugzilla.gnome.org/show_bug.cgi?id=711028

  7. #7
    Join Date
    Jul 2012
    Posts
    799

    Default

    Quote Originally Posted by Bucic View Post
    Tearing on Gnome shell with Intel GPUs is said to be impossible to fix without DRI3 and Mesa 10.
    https://bugzilla.gnome.org/show_bug.cgi?id=711028
    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.

  8. #8
    Join Date
    Oct 2013
    Posts
    27

    Default

    Quote Originally Posted by blackout23 View Post
    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.

  9. #9
    Join Date
    Oct 2008
    Posts
    3,174

    Default

    Quote Originally Posted by vivo View Post
    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.

  10. #10
    Join Date
    Dec 2011
    Posts
    2,106

    Default

    Ubuntu GNOME going with X.org and eventually Wayland.
    Kubuntu going with Wayland.
    Lubuntu and Xubuntu are staying with X.org for the time being.

    It seems nobody is interested in Mir.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •