Announcement

Collapse
No announcement yet.

ATi + (FGLRX) -> at least 3 years old problem..

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

  • ATi + (FGLRX) -> at least 3 years old problem..

    I've been waiting for a fix that never came in the last 3 years, yet the problem could be older. A problem related to Desktop distributions since I tried all major ones - and they're all in same situation.

    Ok, I guess it's not something new for anyone, since many topics related to ATi Proprietary drivers emerged in all this years, but this problem is related to basic functionality and got real annoying to see it's still here after all this time. On the other hand, the guys behind ATi Open Source drivers "FIXED IT"... yet their functionality is even more limited then FGLRX (just recently got 2D acceleration support + some extra from Linux Kernel side) for my card which is HD 4xxx / R700 based cards (as in HD 4850).

    Older cards have better support of course - and that was the Linux tradition since lately, since now I see they're more interested in the present, at least the guys behind Linux Kernel.

    ===================

    Ok, short story....

    I've made a video with the problem... - of course in real life doesn't move like that, but any HD 3xxx/4xxx/5xxx user should know what I'm talking about...

    This problem has some roots in Windows as well, but Linux has a different functionality... as in - you rarely move any Windows in Windows (irony I know) unless you have a multi display config - yet Linux can go by Multi Desktop options for those that use it and it's noticeable...

    It's even noticeable in Videos and guess it's related... There is some kind of horizontal line Flicker that goes from Down -> UP. Could be related, not really sure - yet this problem seems new, are maybe I'm mistaken....

    All I know is, none of the above problems are present with Open Source drivers... yet owning a HD 4850 card and using it at 30% of her potential it's not really acceptable...

    They want to keep the drivers proprietary, that's their business... but since I bought their product I would advise them to think about those who support them *** well... I owned/own 3 ATi cards in the last 6 years that should count for something. If they can't compete with nVidia when it comes to drivers support they should lower their pride, cause honestly they disrespect their clients with their pride.

    -----

    If somebody know a workaround i'd appreciate it ...

    If you own a HD 3xxx/4xxx/5xxx just check:with Open Source Drivers (the ones that come installed by default with Ubuntu 10.04 LTS) and FGLRX drivers...

    I mean, this is related to basic functionality...

  • #2
    It's called "V-Sync". And it's not supported by fglrx with compositors (Compiz/KWin4/etc.)

    Comment


    • #3
      I thought about that... and that could be the cause, since the tearing/flicker problems seem familiar to this situation.

      Yet if you check the video again, you'll see that all effects are disabled.

      ======

      I mean, how complicated is to fix this, since on Windows they interact with heavy graphic applications like games that run just fine?

      On the other hand, how did the guys behind Open Source drivers fixed it, that runs fine both with videos and compiz? And all that whit "WHAT THEY HAD" - compared to ATi which have full knowledge regarding their hardware.

      Comment


      • #4
        The vsync code in the open source drivers was written by an ATI/AMD developer (Alex) with access to hardware info.

        AFAIK the solution used in the open drivers (polling display hardware directly from the userspace driver) is not feasible for fglrx due to some architectural differences between the drivers, but I haven't spent much time on it.

        Comment


        • #5
          BTW there is a known problem with tearing on Xv output with fglrx but if you use GL output for video and enable sync-to-vblank for GL that should eliminate the tearing unless you are running with a compositor (which you say you are not).

          Comment


          • #6
            Originally posted by bridgman View Post
            The vsync code in the open source drivers was written by an ATI/AMD developer (Alex) with access to hardware info.

            AFAIK the solution used in the open drivers (polling display hardware directly from the userspace driver) is not feasible for fglrx due to some architectural differences between the drivers, but I haven't spent much time on it.
            That's just it - the guys behind Open Source had to use a workaround to make them functional since they don't have the documentary resources of the once that made the hardware (in this case ATi). Sort story - sort ATi should be a lot easier to get same results...


            Originally posted by bridgman View Post
            BTW there is a known problem with tearing on Xv output with fglrx but if you use GL output for video and enable sync-to-vblank for GL that should eliminate the tearing unless you are running with a compositor (which you say you are not).

            Didn't use any in that Video to make a point... but I would like to use them.

            Comment


            • #7
              I've seen this problem before. When I had it, it was always just the driver that hadn't installed itself correctly.

              Did you make sure to completely uninstall any video driver package before you installed the new driver, and did you make sure to set it up correctly?

              I remember when I installed FGLRX I got that one on several occations. Rebooting or anything didn't help, but if I completely reinstalled the driver and then ran aticonfig --initial -f from a terminal after installing but before restarting it would go away. (I have no idea exactly why though)
              Maybe there's something similar going on with the Open source drivers?

              Comment


              • #8
                Originally posted by Vii7 View Post
                That's just it - the guys behind Open Source had to use a workaround to make them functional since they don't have the documentary resources of the once that made the hardware (in this case ATi). Sort story - sort ATi should be a lot easier to get same results...
                Huh ? I think you're missing the point here - Alex *is* one of the key open source driver developers, and was co-maintainer of the radeon driver long before he came to work for ATI/AMD.

                Comment


                • #9
                  The information he used *is* publicly available, by the way - Alex just happened to be one of the primary developers of the open source driver. He *also* has access to internal info (he uses it to write a lot of the documentation we release) but that wasn't relevent to this specific issue.

                  Comment


                  • #10
                    For completeness, I believe the initial work was done by Alex, then Alex + Pierre Ossman both helped bring it to completion.

                    Comment

                    Working...
                    X