Announcement

Collapse
No announcement yet.

Mesa 7.1 Released, X.Org 7.4 Coming!

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

  • #16
    Originally posted by mityukov View Post
    Why X11 overlay? I thought Radeon os-driver, already provide good support for Xv (via TextureVideo)?

    http://wiki.x.org/wiki/RadeonFeature


    In general, I think I can live without OpenGL 2/3 for now. Just let 2D(EXA), Desktop Effects and Video playback work flawlessly. ;-)

    I understand, that Video/3D apps will flicker in Window mode, when Desktop Effects on, till somebody implement DRI2.. But I'm expecting that there are no reasons no to play them played correctly in the following cases:
    - Desktop Effects: OFF -- Video/3D to be played correctly in both Window/Fullscreen mode;
    - Desktop Effects: ON -- Video/3D to be played correctly in Fullscreen mode.

    Can we really expect something like this?



    And finally: what about AIGLX? Isn't that required for normal functioning of Compiz-like WMs on ATI/AMD cards? Or, this is a part of Xorg (how to check fo which Cards 7.4 has hardware-accelerated AIGLX)?


    P.S.: please forgive me so many questions. I liked the news too much, and can't stop myself :-p
    Thanks for the link.
    It seems RS690 & R500 (the two cards I have), have most things working, mainly some 3D stuff and GLSL missing. Hopefully they'll be implemented sometime soon.

    @bridgman: So if I get this Mesa release, will I be able to use Xv video with compiz, no flicker?

    Comment


    • #17
      Mesa shouldn't actually affect your Xv playback - you just need recent radeon, or very recent radeonhd, plus a recent DRM. The Xv code is all in the X driver (radeon/radeonhd) which in turn uses DRM to push 3d engine commands to the GPU.

      Comment


      • #18
        Originally posted by bridgman View Post
        Mesa shouldn't actually affect your Xv playback - you just need recent radeon, or very recent radeonhd, plus a recent DRM. The Xv code is all in the X driver (radeon/radeonhd) which in turn uses DRM to push 3d engine commands to the GPU.
        Oops, I thought that "X driver" is a part of Mesa (its HW branch)..
        The more I read about all this stuff, the more it's mixing in my head. %)

        What about AIGLX? Which of X component is responsible for it? And will the installation of today's Mesa and forthcoming X.Org 7.4 bring AIGLX support?

        (there were some notes in the concurrent topic [Installing open-source radeon/radeonhd driver], that AIGLX (and therefore Compiz) "is not supported when using mesa 7.1 packages unless you also upgrade your xserver"..

        Xserver and Xorg are different pieces of X, right?

        Comment


        • #19
          Originally posted by mityukov View Post
          Xserver and Xorg are different pieces of X, right?
          Xserver is one of the packages of Xorg. In other words, Xorg is a collection of packages and Xserver is one of them.

          Comment


          • #20
            Let's see...

            The X server is the "framework" which includes a lot of common code. In the simplest case it loads a single X driver, which controls the graphics chip. Applications (called clients in X-speak) talk to a library (XLib or XCB) which sends commands to the X server. The X server then calls the X driver to set modes and do simple 2D drawing.

            So far we are only using the X driver, not the DRM driver or the Mesa driver.

            Getting a bit fancier, the application can make calls to the lib for things like accelerated video playback or 3D drawing. Video playback is handled by the X driver, which in turn may load and use a DRM driver (aka kernel driver), in which case the X driver will normally talk through the DRM driver to control the chip. I'll explain why in a bit.

            3D drawing is done by having the X server call the Mesa, or 3D driver. Mesa can either do software rendering (using the CPU) or hardware-accelerated rendering if the right driver code is included. When Mesa is doing hardware accelerated rendering it normally goes through the DRM driver as well.

            So far all of the drawing is what we call "indirect", where the app calls a lib, which sends commands to the server, which then calls the appropriate drivers (X driver for 2d & video, Mesa for 3D) to do the actual drawing. When we draw 3D this way with hardware acceleration, we call it AIGLX, or Accelerated Indirect GL through X.

            Now, AIGLX is relatively recent. Before AIGLX, drawing 3D through the X server was normally pretty slow because it was done in software. The normal way to get 3D acceleration was via the "direct rendering infrastructure", or DRI. In this case the application calls went directly to the Mesa driver, bypassing the X server. Mesa then called the DRM driver, which coordinated use of the chip between the Mesa driver and the X driver. In this model, 2D and video acceleration went through the X server, the X driver, and the DRM driver, while 3D acceleration went directly to Mesa and then the DRM driver.

            OK ? Direct vs Indirect rendering. Three drivers - X driver (xorg/driver/xf86-video-ati aka radeon or xorg/driver/xf86-video-radeonhd), DRM driver (mesa/drm), Mesa driver (mesa/mesa).

            To add to the confusion, the DRM and Mesa drivers are not part of Xorg, so they are released independently of Xorg. This worked back when X mostly cared about 2D and video playback, but doesn't work so well today. The obvious answer is to include DRM and Mesa as part of Xorg, but it's not that simple because DRM ends up being integrated into the Linux kernel (or the BSD kernel, or Solaris kernel, or...) so maybe DRM should live in one of those kernel trees instead. This is all being hotly debated today.

            Don't even THINK about trying to understand XGL
            Last edited by bridgman; 08-27-2008, 01:23 PM.

            Comment


            • #21
              Thanks a lot. I'll probably will need to draw a chart, using everything that I read here..

              Originally posted by bridgman View Post
              Video playback is handled by the X driver, which in turn may load and use a DRM driver (aka kernel driver), in which case the X driver will normally talk through the DRM driver to control the chip. I'll explain why in a bit.

              ...

              In this model, 2D and video acceleration went through the X server, the X driver, and the DRM driver, while 3D acceleration went directly to Mesa and then the DRM driver.
              Sorry, does it mean that Direct 3D calls are not used, when playing Videos, and it's closer to 2D in the way how it's performing? Why it flickers in Compiz, just like any other 3D app, then?

              I mean.. Is there a chance that the Video would be played in with Desktop Effects enabled _before_ DRI2 implementation?


              By the way: were there any considerations about having some sort of "X Windows system: Desktop edition" - without Network transparency requirements or so (I mean, free of "Client-server" model).
              Last edited by mityukov; 08-27-2008, 03:36 PM.

              Comment


              • #22
                Originally posted by mityukov View Post
                Sorry, does it mean that Direct 3D calls are not used, when playing Videos, and it's closer to 2D in the way how it's performing? Why it flickers in Compiz, just like any other 3D app, then?
                the flicker is not generally caused by 3D apps, but by conflicting accesses to the framebuffer, like when 3D directly renders to framebuffer.

                But it is also possible to render Videos directly to framebuffer, which is how the Xv Overlay works.

                Originally posted by mityukov View Post
                I mean.. Is there a chance that the Video would be played in with Desktop Effects enabled _before_ DRI2 implementation?
                it should already play fine with desktop effects enabled, if you use textured video.

                you have probably configure it using "gstreamer-properties".

                Originally posted by mityukov View Post
                By the way: were there any considerations about having some sort of "X Windows system: Desktop edition" - without Network transparency requirements or so (I mean, free of "Client-server" model).
                this does not make sense.

                Comment


                • #23
                  Wow! Mesa 7.1 officially released. This is surely a sign of the Apocalypse. The next thing you know, The Four Horsemen will show up (I'm going to offer them a beer).

                  This is a good read (summarizes the different aspects of X rendering):
                  http://www.rojtberg.net/67/exa-uxa-dri-gem-ttm/
                  Last edited by DanL; 08-27-2008, 07:41 PM.

                  Comment

                  Working...
                  X