Announcement

Collapse
No announcement yet.

Is there a back to basics solution to tearing?

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

  • #11
    AKA switch to gentoo
    eh?

    The stuff in "arch" is fairly long in the tooth. The stuff in "~arch" is maybe on par with what Ubuntu and OpenSUSE shoved out of their last release.

    I know about layman... I'm running the x11 overlay on my laptop (X1300 video card, if that doesn't explain it). Maybe I'm doing something wrong, but it doesn't seem like there's been that much activity with that overlay. I sync my portage tree and the overlay every few days, and x11 has told me I've been up to date for the past three weeks.


    Or did you just mean that with a Gentoo system, most everything you'd need for a build environment is already there from the word "Go"?

    Comment


    • #12
      Originally posted by bridgman View Post
      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.
      Does 'fairly soon' apply to both ati and radeonhd drivers?

      Comment


      • #13
        3d Acceleration is independent of the xorg driver, because that's in mesa, where there's only one driver for r500+ cards.

        The Xv implementation will probably be added to both the xorg drivers fairly quickly, since they share a lot of code.

        Comment


        • #14
          Originally posted by TechMage89 View Post
          3d Acceleration is independent of the xorg driver, because that's in mesa, where there's only one driver for r500+ cards.

          The Xv implementation will probably be added to both the xorg drivers fairly quickly, since they share a lot of code.
          Thanks for the explanation. So does this mean that if I've got a r500+ card, it is largely irrelevant which driver I use for 3d gaming?

          Comment


          • #15
            Originally posted by TechMage89 View Post
            3d Acceleration is independent of the xorg driver, because that's in mesa, where there's only one driver for r500+ cards.

            The Xv implementation will probably be added to both the xorg drivers fairly quickly, since they share a lot of code.
            So, just make things clear for now on (at least for me!)

            There is NO hardware accelerated video playback support on the xf86-ati (radeon), right?

            Comment


            • #16
              Originally posted by hobbes View Post
              So, just make things clear for now on (at least for me!)

              There is NO hardware accelerated video playback support on the xf86-ati (radeon), right?
              xf86-video-ati supports hw accelerated video playback (colorspace conversion and scaling) for r1xx-r5xx cards. Only r6xx lacks acceleration at the moment.

              Comment


              • #17
                . I sync my portage tree and the overlay every few days, and x11 has told me I've been up to date for the past three weeks.
                The ebuilds with version number 9999 are straight from git. When using this ebuilds you won't see any updates n a simple emerge -avuD world. This also wouldn't make any sense since there is pretty much always a change (except you update multiple times a day). Simply re-emerge the packages with version 9999 to stay up to date.

                Comment


                • #18
                  I was referring to Xv for r600+. Both drivers have support for Xv through r500.

                  Comment


                  • #19
                    For clarification :

                    - there are two parts to video acceleration, decode and render
                    - render is usually the most time consuming; Xv is the API for render acceleration, both open source and fglrx implement Xv acceleration
                    - open source drivers do not have video render acceleration for r6xx/7xx yet but getting close

                    - decode is not accelerated on either driver today
                    - decode has three main parts: IDCT, MC, "everything else"
                    - MC is typically most CPU intensive decode task; R5xx accel docs include enough info to write MC acceleration AFAIK
                    Test signature

                    Comment


                    • #20
                      Originally posted by bridgman View Post
                      For clarification :

                      - there are two parts to video acceleration, decode and render
                      - render is usually the most time consuming; Xv is the API for render acceleration, both open source and fglrx implement Xv acceleration
                      - open source drivers do not have video render acceleration for r6xx/7xx yet but getting close

                      - decode is not accelerated on either driver today
                      - decode has three main parts: IDCT, MC, "everything else"
                      - MC is typically most CPU intensive decode task; R5xx accel docs include enough info to write MC acceleration AFAIK
                      Thank you for clearing that out.

                      Perhaps, that explains why some x264 video (1280x720p, real ones) drop some frames and lags on some "actions scenes" or "too wide, too many detailed background scenes"

                      I can precisely point out this scene of Terminator (1984).

                      uploaded sample: http://rapidshare.com/files/142752531/T1.Sample.avi

                      (1920x720p, x264/AC3, 03:10 min, 195,5 MB) Sorry for the file size, but it is all in there.

                      I can not play this particular action scene without jumping too many frames or totally losing A/V sync.

                      Totem (gstreamer or xine), mplayer or vlc can't do it.

                      It is the toughest scene I've encountered so far.

                      Things get messy after the explosion scene. I took the liberty to edit leaving some seconds before, just to preserve most of the integrity of it on some "unknown editing issue"

                      Maybe this particular sample would be a great asset to fully optimizing HD playback on R500. I would hope so.

                      It can't also be played on Catalyst. At least version 8.6, the last one I have used before switching - for good, I hope - to radeon open source driver.

                      My system can playback a 720p real file. At least on theory.

                      Hardware:

                      Sapphire AGP X1600 pro + Pentium D + 2GB RAM + Debian SID + Experimental packages. The same occurred using Intrepid.

                      Software:

                      xserver-xorg-core: 2:1.4.99.906-2
                      libgl1-mesa-dri: 7.1-1
                      xserver-xorg-video-radeon: 1:6.9.0+git20080826.a3cc1d7a-1

                      PS: Perhaps a creation of a Thread with some uploaded 720p samples could lead to some new HD playback improvements on the future. What do you guys think of that?
                      Last edited by hobbes; 05 September 2008, 03:48 AM.

                      Comment

                      Working...
                      X