Announcement

Collapse
No announcement yet.

Compiz + Ati + Xv/OpenGL = Huh?

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

  • Compiz + Ati + Xv/OpenGL = Huh?

    Okay, while I don't dable in Linux as much as I used to (partially due to issues like the one I'm about to go into), I do fondly remember when Xgl and Compiz hit the scene, long before the Beryl fork or the Compiz-Fusion merger.

    I remember one simple issue back then. Back on my Radeon 9600, I was able to get Compiz working with XGL and all was good. Then I tried playing a video or running a 3D program and everything went to hell.

    At the time, I started looking for solutions to this issue, and the general consensus was that the solution to all our problems was either XeGL or AIGLX, whichever got around to working properly first.

    Fast forward a few years and now the holy grail is DRI2 for flicker-free playback. Fantastic. However, having just gotten a Radeon 4850 and trying out Compiz, months after Ati supposedly got AIGLX into their FGLRX driver, I really need to ask...

    Why on Earth does video playback and 3D still not work? I mean, at all. I tried running glxgears and it appears to never leave its screen block, even when rotating the cube. I try playing a video, and it's a flickery mess with the exact same problem. Heaven help me if I try running Blender, which is suddenly incapable of opening in "windowed mode", and behaves erratically as it is.

    Wasn't the big FGLRX update supposed to fix all of this? I wondered if I was the only one with this issue, but then I looked it up and this seems... standard. Does anyone's fglrx-powered Ati card NOT do this?

    Because as it stands, it seriously looks like AIGLX support was essentially a "lie" in that it "works" but the entire purpose of supporting it is completely lost. I mean, in all honesty, what exactly is the difference between this and using Xgl 3 years ago? I'm half upset and half confused as to why this seems to be the case. Is there a workaround I don't know about? (Ha ha ha, no, disabling Compiz isn't a workaround )

  • #2

    Comment


    • #3
      Originally posted by mukiex View Post
      Okay, while I don't dable in Linux as much as I used to (partially due to issues like the one I'm about to go into), I do fondly remember when Xgl and Compiz hit the scene, long before the Beryl fork or the Compiz-Fusion merger.

      I remember one simple issue back then. Back on my Radeon 9600, I was able to get Compiz working with XGL and all was good. Then I tried playing a video or running a 3D program and everything went to hell.

      At the time, I started looking for solutions to this issue, and the general consensus was that the solution to all our problems was either XeGL or AIGLX, whichever got around to working properly first.
      Anybody who said that AIGLX would fix the flickering problem with video playback and 3D applications at the same time as compiz did not know what they were talking about. It was certainly known, even before AIGLX was available in fglrx, that DRI2 would be needed to solve the opengl flickering problem. The video flickering problem does not require DRI2 to fix, but simply properly implemented textured video (which the open source drivers now support on r100-r500 cards).

      Adam

      Comment


      • #4
        Right. AIGLX was an alternative to XGL for allowing something like Compiz to run. AIGLX was felt to be cleaner and more versatile but I think you could argue with some success that Compiz over AIGLX was actually a bit *less* capable than Compiz over XGL.

        I'm still not 100% sure about this, but the real "flickering 3D" problem seems to be that AIGLX provides a nice "indirect rendering" solution for 3D under Compiz but nearly all 3D apps use "direct rendering" instead. Direct rendered apps don't know about the compositor and so they end up drawing to the same area of the screen as Compiz and the result is flickering.

        By the way DRI2 on its own won't solve your problems either. What you really want is Redirected Direct Rendering, which builds on both DRI2 and GEM/TTM.
        Last edited by bridgman; 19 December 2008, 11:21 AM.
        Test signature

        Comment


        • #5

          Comment


          • #6
            DRI2 requires a memory manager, doesn't it? So simply saying that DRI2 will resolve the problem is correct :-)

            Adam

            Comment


            • #7
              My understanding was that RDR needed some work in addition to DRI2. Maybe that has changed, ie maybe DRI2 includes RDR these days. Only krh knows for sure.

              I agree that assuming DRI2 includes MM makes sense.
              Test signature

              Comment


              • #8
                Originally posted by thacrazze
                btw, the story is that nVidia "fixed" this a long time ago by reimplementing a lot of Xorg, including a lot of stuff that wasn't there (I think it was mainly to do with the memory manager), and made their own framework for RDR and stable vsync. Presumably the fglrx people have done the same thing now, but hopefully their job was made a little easier by new code in Xorg going that way anyway

                Comment


                • #9
                  Originally posted by grantek View Post
                  btw, the story is that nVidia "fixed" this a long time ago by reimplementing a lot of Xorg, including a lot of stuff that wasn't there (I think it was mainly to do with the memory manager), and made their own framework for RDR and stable vsync. Presumably the fglrx people have done the same thing now
                  They didn't. And I don't think they will, unfortunately.

                  Comment


                  • #10
                    Originally posted by RealNC View Post
                    They didn't. And I don't think they will, unfortunately.

                    Comment

                    Working...
                    X