Announcement

Collapse
No announcement yet.

Intel Driver Gets DRI2, KMS Approaching

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

  • Intel Driver Gets DRI2, KMS Approaching

    Phoronix: Intel Driver Gets DRI2, KMS Approaching

    Times are already exciting within the X.Org development community thanks to the Graphics Execution Manager entering Linux 2.6.28 and the release of X Server 1.6 quickly approaching, but still there's more good news to report this week. The Direct Rendering Infrastructure 2 support has entered the mainline xf86-video-intel driver and DRM mode-setting (commonly referred to as kernel mode-setting) has appeared in the drm-intel-next branch. Intel's driver has worked with DRI2 already, but now it's finally entering their mainline tree to appear in Intel's next driver release (xf86-video-intel 2.6)...

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

  • #2
    Yup! I pulled the code for this out of GIT just last night. Kind of unstable, though, as Compiz instantly freezes everything. Xfce4's compositor still works.

    Comment


    • #3
      Wow, that is great!
      January will be a fantastic month with GEM in 2.6.28, Xserver 1.6, Intel 2.6 and KDE 4.2!

      Comment


      • #4
        The dri2 introduction will improve the 3d performances of intel and ati drivers?
        Xwang

        Comment


        • #5
          Thanks for the news Phoronix. Don't think I don't think you guys do a good job.

          The dri2 introduction will improve the 3d performances of intel and ati drivers?
          Probably not right away. The X/Kernel hackers are going to concentrate more on getting it stable and such before they worry about performance issues too much... but what it is is a huge step in the right direction.

          All of this is essentially taking the X/Linux driver model and dragging it out of the mid-1990's era technology and into something that is much more capable and modern. A big change.

          This means that it opens up the way for stable composited desktops, nicer graphical experiences, support for programmable shaders, and better video acceleration.

          Comment


          • #6
            Originally posted by Xwang View Post
            The dri2 introduction will improve the 3d performances of intel and ati drivers?
            Xwang
            Look at the screenshot I posted above. Notice how the video being played is partially transparent over the GLXGears demo program. Until DRI2, this was not possible with X11's OpenGL renderer. The GLXGears program (along with other 3D programs) would always render ON TOP of whatever was being shown, given a 3D accelerated desktop. DRI2 introduces what's called "redirected direct rendering." This allows GL apps to be rendered to a different buffer, and then having that buffer treated like any other window being drawn.

            GEM is what will increase the performance of the drivers.

            Comment


            • #7
              does gallium3d use dri2? otherwise asked: if we ever have gallium3d, do we still need dri2 or is it obsolete by this date? (don't get it :/ )

              Comment


              • #8
                Finally

                Finally we will have the graphics subsystem that we were supposed to have, only a year later than originally planned. Hopefully everything will be in place when 2.6.29 lands, whenever that will be.

                Comment


                • #9
                  It's kind of sad that Windows Vista has had this ability since it launched.

                  Comment


                  • #10
                    Originally posted by Regenwald View Post
                    does gallium3d use dri2? otherwise asked: if we ever have gallium3d, do we still need dri2 or is it obsolete by this date? (don't get it :/ )


                    Well as you probably know the OpenGL acceleration for Linux is provided by 2 sets of drivers. There is a userspace part and then a kernel part.

                    The userspace part is the DRI driver.
                    The kernel part is the DRM driver.

                    The DRI drivers talk to the kernel DRM driver using the DRI protocol.

                    Originally DRI rendered OpenGL acceleration directly to the video card's video RAM. Which is why it's ugly on composited desktops.

                    So DRI2 was made to match the requirements of new hardware. It also renders graphics to offscreen buffers which then can be incorporated into your desktop via compositing, which makes everything much nicer looking.

                    In order to get DRI2 working more effectively we need advanced memory management facilities. That's what GEM gives us. GEM is part of DRM.

                    Also in order to get DRI2 working a new DRI2 interface with DRM was created.

                    Soo.... How does Gallium come into it?


                    Well a DRI-style driver is very complicated. It provides a lot of functionality, but only a small part of the functionality is really hardware-specific.

                    So Gallium is a modular DRI2 driver. It communicates with the in-kernel DRM via the DRI2 protocol and it tries to divide up the hardware-specific portions from the OpenGL stuff. The hardware-specific part is called 'Winsys' (I think).

                    By doing this then Gallium can be used to accelerate lots of different APIs instead of OpenGL. OpenCL... OpenRT... video playback acceleration. etc etc.
                    Last edited by drag; 12-07-2008, 05:20 AM.

                    Comment


                    • #11
                      ok, thanks for explanation! i see more and more light in the dark
                      i'm missing a mesa/drm roadmap. and what's the mesa's state (when comes ogl3)? does it need optimizations (aka is it also in such a sad state such as the other x related things?)? sry for ot, but there are some skilled people here...

                      Comment


                      • #12
                        drag, thanks a lot for your explanation. It's very clear and make it possible to see the wider picture to a lot people.

                        I think that could be used as a basis to explain why all DRI2, GEM and Gallium is so interesting and even revolutionary.

                        Maybe doing a video presentation for dummies about all this could be interesting (with subtitles to different languages, I could help in the Spanish ones), so people can see FLOSS will be advanced in the graphics stuff too. What about Phoronix TV?

                        Comment


                        • #13
                          Originally posted by wswartzendruber View Post
                          It's kind of sad that Windows Vista has had this ability since it launched.
                          Well once it is fully implemented, all this should be even BETTER than *cough* Vista *cough*

                          Comment


                          • #14
                            i'm missing a mesa/drm roadmap. and what's the mesa's state (when comes ogl3)? does it need optimizations (aka is it also in such a sad state such as the other x related things?)? sry for ot, but there are some skilled people here...
                            Quick answer is that there is a lot of room for optimizations in Mesa and the rest of the 3D stack. If I had to nitpick I would probably say that the 3D side of the stack needs more work than X and its drivers. I guess you could identify four classes of work :

                            1. Moving from the existing HW driver model to Gallium3D - Gallium3D itself should make better use of newer chips and bring a better shader compiler (although I have some doubts about whether LLVM's optimizers will really be applicable to the kind of SIMD hardware we use in modern GPUs).

                            2. Improving the way that work is passed from the Mesa driver (DRI driver in drag's summary) to the DRM driver to allow more pipelining and less frequent flushing of GPU hardware.

                            3. Making use of new memory manager capabilities to get the effect of having more RAM available - I'm not talking virtual memory here as much as just making full use of the memory available on the card.

                            4. Getting better at managing GPU state so we don't need to send so much information down to the hardware over and over again.

                            Parts #1, #2 and #3 are underway now, although a lot of the work is currently being done in side branches. #2 is partially driven by availability of HW documentation and support -- the rest are "software only" initiatives, ie the result of a bunch of smart guys working together over a couple of years. Part #4 may dribble in over time or there may be a deliberate attempt to design around state managment - not sure which makes more sense right now.

                            Our feeling is that the open driver should be able to get somewhere between 50 and 70% as fast as fglrx. We will be providing enough HW information to make it 100% as fast (or faster) but the amount of developer effort required goes up exponentially once you start getting into the per-application profiling and continual re-optimization needed to get that last 30%.
                            Last edited by bridgman; 12-07-2008, 02:27 PM.

                            Comment


                            • #15
                              Originally posted by bridgman View Post
                              Our feeling is that the open driver should be able to get somewhere between 50 and 70% as fast as fglrx. We will be providing enough HW information to make it 100% as fast (or faster) but the amount of developer effort required goes up exponentially once you start getting into the per-application profiling and continual re-optimization needed to get that last 30%.
                              Great! We cannot ask for more. Thank you so much for this.

                              PS: Hopefully there will be an easy way of power saving in linux (like already available for CPUs).

                              Comment

                              Working...
                              X