Announcement

Collapse
No announcement yet.

End user benefits of the new X technologies

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

  • End user benefits of the new X technologies

    I've been somewhat confused about the new X features in development. Could someone write a summary about the benefits of GEM/KMS/TTM/DRI2 etc. from the users' point of view?

  • #2
    GEM is the new memory manager replacing TTM. It is said to enable better memory managment which to the end user means better acceleration - when drivers using it are well developed.

    KMS enables changing VT's (i.e. to X and out of X) without all that blinking, flickering and whatever - so it'll look better and the name Kernel Mode Setting suggests taking the code out of Xorg and into the kernel.

    DRI2 is the new rendering infastructure. When drivers make good use of it, thing should be better, faster, more reliable than with DRI. I guess ;]

    Comment


    • #3
      Yep. To me the "big deal" aspects are :

      1. GEM/TTM give us a general-purpose memory manager in the kernel, which allows X and Mesa to share memory objects properly for the first time. Sharing memory objects between X and Mesa helps a lot with things like pixmap/texture conversion (you don't need to copy any more) and is a pre-requisite for KMS, DRI2 and some higher-level GL functions.

      TTM had barely been implemented before being replaced with GEM, so the "big deal" here is not so much GEM replacing TTM as having a decent memory manager in the kernel module (drm) where we didn't have one before.

      2. KMS allows all of the different graphics drivers to be replaced with a single driver in the kernel, so rather than passing control from one driver to another when doing a VT switch or suspend/resume one driver can maintain control all the time. This will hopefully eliminate a class of problems and make VT switch & suspend/resume more reliable.

      3. DRI2 is being used as a foundation for Redirected Direct Rendering in the open drivers (the ability to redirect the output from a direct-rendering application through a compositor) which will allow flicker-free 3D under Compiz, among other things.
      Last edited by bridgman; 06 December 2008, 10:52 AM.
      Test signature

      Comment


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


        • #5
          Gallium3D and dri2 are entirely separate layers, and aren't necessarily dependent on each other. However, the Gallium3D development going on right now is being done to target dri2, because dri2 will be rolled out before Gallium development is going full swing, therefore writing a dri (1) driver would be pretty pointless.

          Actually, Gallium3D doesn't need X, or anything else in particular (you could even in theory write Windows drivers using Gallium3D, I believe). Mesa is designed to be as modular as possible.

          Comment


          • #6
            Yep, Gallium3D is sorta one level higher in the driver stack. Easiest way to think about the direct rendering stack is something like :

            Mesa GL interface (no change)
            Mesa HW driver interface (replace with / rebuild over Gallium3D)
            DRI/DRM (update to use DRI2 protocols instead of DRI1)
            hardware

            Applications call Mesa, which was initially a software GL renderer. It also has an internal driver interface which allows certain functions to be hardware accelerated. That HW driver interface is unique to Mesa. Mesa calls drm to talk to the hardware, and drm uses the DRI protocols to find out important things like "where is the window I am supposed to draw to" and "has the window moved since the last time I drew something ?".

            Gallium3D is a low-level driver interface which is designed around modern shader-based GPUs and is intended to support a number of different high level APIs. Mesa is being modified to use Gallium3D rather than the built-in HW driver interface.

            The DRI code provides a mechanism direct rendering calls through Mesa to stay in sync with window information managed by the X server and with 2d/video rendering done through the X server (aka indirect rendering). DRI2 is a new and simplified version of the DRI protocols and code.
            Last edited by bridgman; 06 December 2008, 10:00 PM.
            Test signature

            Comment


            • #7
              I have read that also KMS will allow to have a Linux BSOD in X So if you get a kernel panic, and you where using X, you will be able to see it.

              What happened to input transformation? Will it be in Xserver 1.6?

              Also what is Glucose? I have read that it is an acceleration architecture for Xorg that uses OpenGL to accelerate X. But what does that mean?

              What is the relation/difference between Glucose and a compositing manager?

              What changes will be requited (or is this already implemented?) to use Glucose?

              Comment


              • #8
                @techmage89 & bridgman: thanks for explanation. the x stack is really complicated

                @KDesK: glucose is something like exa and xaa. as far as i know, glucose could be used by gallium3d as high level api (as brigdman calls in another thread related to intel-things..). or am i missunderstanding something?! (probably )

                Comment


                • #9
                  Thanks to everyone for the explanations. Right now I'm mostly concerned with clean, judder and tear free video playback that doesn't get messed up when using more than one monitor, which depending on the hardware and driver combination seems to be a hit or miss right now. I suppose we will see improvements on that front?

                  Comment


                  • #10
                    Glucose is a 2D acceleration API written over the OpenGL stack. As Regenwald said, these days a Glucose-like API is more likely to be written over Gallium3D (the low level interface) than OpenGL, and I expect the standard EXA and Xv APIs would be used, so what we are really talking about is EXA and Xv being built over Gallium3D rather than directly programming the hardware.

                    Thomas and others have been working on a "generix X driver" which will use KMS for modesetting and Gallium3D for 2D and video acceleration -- that's probably a pretty good hint of the eventual future. I forget what the project is called but the source is in freedesktop.org.
                    Last edited by bridgman; 07 December 2008, 03:28 PM.
                    Test signature

                    Comment

                    Working...
                    X