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

    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
    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.
            All opinions are my own not those of my employer if you know who they are.

            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; 20 February 2013, 01:23 PM.
                All opinions are my own not those of my employer if you know who they are.

                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.
                    All opinions are my own not those of my employer if you know who they are.

                    Comment

                    Working...
                    X