No announcement yet.

Is there a back to basics solution to tearing?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Is there a back to basics solution to tearing?

    Hello there,
    I'm running a pretty standard (fully-updated from their own repos) install of Ubuntu 8.04, on my new Q6600/4GB/Radeon 4850 system. I've installed the Catalyst 8.8 drivers (without any troubles - the last time I did this was back in 2004, when fglrx seemed to require kernel patches and other hoodoo) simply because neither radeon or radeonhd worked out of the box with the 4850.

    My problem is simple - I get tearing on videos and on the edges of windows while moving them horizontally. This is most marked when Compiz is on; particularly with videos which flash uncontrollably and render everything unwatchable. But even with Compiz off, the window-edges still tear, and videos still exhibit vsync issues upon fast panning.

    Now the thing is, I don't really care about fancy visual effects, I don't need Compiz, I don't need the closed source drivers or 3D acceleration. I just want a computer which has a display that I can write my thesis on without making me feel ill, and maybe watch a DVD or two upon. Ubuntu is so nearly there, everything else works flawlessly, and I really don't want to have to go back to Windows - crashes killing or corrupting my work is why I switched to Linux four years ago.

    So the questions are:
    1. Is there anything I can do with my current "fglrx" setup? I fear not - I've tried pretty much everything that two days of googling can turn up, and it looks as though ATI's current vblank interpretation is just fundamentally broken and I should give up, but I thought I'd ask anyway.

    2. So if we accept that, would the latest open source "ati" drivers help? I've heard that through AtomBIOS this produces fairly decent 2D and Xvideo acceleration. If the answer to this is yes, then how would I go about getting and installing these on Ubuntu 8.04? (I know ideally I'd wait for 8.10 which includes these drivers, but I need to start writing in two weeks). I've seen the general tutorial stickied in this forum, but which steps (drivers, DRM modules etc.) would I need for my simple wishes - working 2D and Xvideo, but no compiz or accelerated 3D necessary.

    3. Should I jack this all in, and ask to swap my 4850 for my (Windows-gamer) younger brother's 8800GT? Is the NVidia implementation of vsync actually as functional as I'm lead to believe?

    Many thanks for your time,

  • #2
    vsync on nvidia cards which has overlay works. i dont have a new nvidia card, but textured xv does NOT vsync properly on my quadro.. ofcourse there are also bugs with nvidias overlay stuff.. but that is something i only see on my quadro, not on other nvidias.. and only with high resolution 1080p video.


    • #3
      What is the current thinking about rendering through OpenGL with sync-to-vblank enabled on OpenGL ? Is that working for people ?


      • #4
        By rendering through OpenGL, do you mean setting gstreamer/mplayer/vlc/whatever to use an opengl output rather than Xv, then forcing vsync in the ATI Control Panel?

        I tried that and it didn't solve the misbehaving-overlay type behaviour in video playback - and of course, surely it would do nothing to solve the edge-tearing I'm seeing on Windows?

        (Apologies if I've got the wrong end of the stick entirely)


        • #5
          Yes. Not sure what you mean by "misbehaving-overlay type behavior", but if the tearing you are seeing is caused by lack of sync-to-vblank then playing through OpenGL with sync enabled should eliminate the tearing *if* the player app uses OpenGL in a way that lets the sync-to-vblank be effective. That's the part I'm not sure about.


          • #6
            Originally posted by bridgman View Post
            Yes. Not sure what you mean by "misbehaving-overlay type behavior", but if the tearing you are seeing is caused by lack of sync-to-vblank then playing through OpenGL with sync enabled should eliminate the tearing *if* the player app uses OpenGL in a way that lets the sync-to-vblank be effective. That's the part I'm not sure about.
            Hi bridgman, I appreciate the efforts of you all on the ATI/AMD team.

            With Compiz on, the video under OpenGL+sync-to-vblank flickers just as it did when using Xvideo. Indeed, the video seems to hover above any other open window.
            With Compiz off, it seems to fix tearing in the video itself. This is progress, certainly. But (without wanting to sound ungracious) it doesn't fix the bigger issue - there's still tearing when I move that video window around on the screen, and there are certain other sources (for example, BBC iPlayer videos in Flash Player, which makes up a large proportion of viewing in the UK) which cannot be easily redirected to a different output filter.

            I suppose the question is, failing any possible tweaks to fglrx, would xserver-xorg-video-ati do anything to help this?


            • #7
              There are actually two completely separate issues here.

              The flickering under Compiz is happening because both Compiz and the Xv driver are trying to write into the same area on the screen. "Misbehaving overlay-type behaviour" is actually a pretty good name for it. Once we get 6xx/7xx acceleration added to the open source drivers (which should be fairly soon, at least for video acceleration) that should take care of the Compiz flickering.

              There is an "unredirect fullscreen windows" option in Compiz which will help with fullscreen video but I realize most folks like to play video in a window.

              The tearing when you are not running Compiz but dragging a window is happening because the drawing ops which *move* the window (via the X driver) are not synced to vblank even if the drawing of video *into* the window is synced properly via the OpenGL driver. That will take a bit longer because the mechanism for handling sync-to-vblank for anything other than OpenGL is kinda being redesigned now and my guess is that it will show up around the same time as DRI2 (ie pretty soon).
              Last edited by bridgman; 09-02-2008, 09:14 PM.


              • #8
                Ah, that makes sense completely - it's rather a shame, as I gather DRI2 has been written out of the upcoming Xorg release until they sort the memory management issues, so I figure it'll be at least 6 months until we can expect a fix?

                In that case, I'll probably try an NVidia card for now (at least to see if it fixes the issue), then try my Radeon again during the academic vacation (June 2009). I was possibly planning to buy another 4850 and Crossfire them then, anyway. Hopefully the driver and X scene will look a little different in nine months.



                • #9
                  Kristian's new DRI2 code is starting to go into the tree now, so I don't think the wait will be as much as 6 months, at least for the more aggressive distros.


                  • #10
                    AKA switch to gentoo

                    Glad to hear DRI2 and memory management are coming along nicely. I'm waiting/excited to check out the new code.