Announcement

Collapse
No announcement yet.

DRI3 Support Comes For X.Org GLAMOR

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Comment


    • #3
      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?
      Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

      Comment


      • #4
        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.

        Comment


        • #5
          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.

          Comment


          • #6
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X