Announcement

Collapse
No announcement yet.

DRI3000 (DRI3) Begins To Take Shape Again

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

  • DRI3000 (DRI3) Begins To Take Shape Again

    Phoronix: DRI3000 (DRI3) Begins To Take Shape Again

    Immediately following XDC2012 there was a lot of talk about "DRI3", but nothing materialized in time for the forthcoming X.Org Server 1.14 release. The DRI3 plans haven't died off but now Keith Packard is talking about this next Direct Rendering Infrastructure update as DRI3000...

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

  • #2
    Plan9 was right

    > DRI3 still revolves around using POSIX file descriptors for passing kernel objects between the X Server and the application.

    I wouldn't have thought that Plan9's concept are useful even on low level frameworks!

    Comment


    • #3
      Originally posted by renox View Post
      > DRI3 still revolves around using POSIX file descriptors for passing kernel objects between the X Server and the application.

      I wouldn't have thought that Plan9's concept are useful even on low level frameworks!
      "Everything is a file" is one of the defining features of Unix.

      Unix's successor Plan 9 took this concept into distributed computing with the 9P protocol.

      Comment


      • #4
        Interesting to see new work being done for X.org even though there is development going on for Wayland.

        Comment


        • #5
          Dri is used with wayland.

          Comment


          • #6
            Originally posted by garegin View Post
            Dri is used with wayland.
            Kernel-side infrastructure of it, maybe. But not the exact extensions, they can't. The extensions are X specific. Unless you're talking about the XWayland backend, but thats different.

            Comment


            • #7
              Originally posted by Ericg View Post
              Kernel-side infrastructure of it, maybe. But not the exact extensions, they can't. The extensions are X specific. Unless you're talking about the XWayland backend, but thats different.
              I hope supporting both x and wayland doesn't slow things down. Progress in already at a glacial pace.

              Comment


              • #8
                Originally posted by garegin View Post
                I hope supporting both x and wayland doesn't slow things down. Progress in already at a glacial pace.
                XWayland is just a shim-layer that gets created when you have an X Client that cant also be a Wayland Client. It creates an X server the exact size of the window in question and X is tricked into thinking its in charge when in reality Wayland is a puppeteer over head directing things to be how they want and how they SHOULD be in the Wayland world.

                Its actually a fairly elegant solution since X clients dont have to change at all and I dont think its in the way of anything in the Wayland world since there's no guarantees that an X Client will be up at any given time. Its basically just an optional code-path that only gets called if an X client somehow appears.


                EDIT: Or did you mean "Supporting" as in developer manpower? I doubt it... All the X devs are Wayland devs for the most part, they know Wayland is the future and that updating X is pretty much just a "Here's some work for us to better the community until KDE hits 5.0 and every Qt and KDE program becomes X/Wayland compatible" lol
                Last edited by Ericg; 02-20-2013, 12:23 PM.

                Comment


                • #9
                  Originally posted by Ericg View Post
                  XWayland is just a shim-layer that gets created when you have an X Client that cant also be a Wayland Client. It creates an X server the exact size of the window in question and X is tricked into thinking its in charge when in reality Wayland is a puppeteer over head directing things to be how they want and how they SHOULD be in the Wayland world.

                  Its actually a fairly elegant solution since X clients dont have to change at all and I dont think its in the way of anything in the Wayland world since there's no guarantees that an X Client will be up at any given time. Its basically just an optional code-path that only gets called if an X client somehow appears.


                  EDIT: Or did you mean "Supporting" as in developer manpower? I doubt it... All the X devs are Wayland devs for the most part, they know Wayland is the future and that updating X is pretty much just a "Here's some work for us to better the community until KDE hits 5.0 and every Qt and KDE program becomes X/Wayland compatible" lol
                  do you think distro can ship xwayland by the end of the year when it gets merged? kde 5 is a long way off.

                  Comment


                  • #10
                    Originally posted by garegin View Post
                    do you think distro can ship xwayland by the end of the year when it gets merged? kde 5 is a long way off.

                    Hopefully XWayland will get merged into the next Xorg release, hopefully.

                    Comment


                    • #11
                      So am I understanding this correctly in that it only applies to Xorg, and not Wayland? Ie. that Wayland has no use for an update to DRI2?

                      Comment


                      • #12
                        Originally posted by runeks View Post
                        So am I understanding this correctly in that it only applies to Xorg, and not Wayland? Ie. that Wayland has no use for an update to DRI2?
                        As far as I know, correct. DRI, DRI2 and DRI3(000) are X-protocol extensions. Wayland is not the X-protocol, its the Wayland (or W) Protocol. They may use parts, concepts, maybe even functions from DRI(1-3(000)) but the DRI stack was designed as an X-protocol extensions

                        Comment


                        • #13
                          ^ I think this is correct. The following thread on LWN explains that DRI2 is an X extension that allows application to allocate a buffer in GPU memory while Wayland/Weston just uses DRM to do this.

                          http://lwn.net/Articles/492670/

                          Comment

                          Working...
                          X