Announcement

Collapse
No announcement yet.

Catalyst 10.2 is out

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

  • Originally posted by Pfanne View Post
    i recently installed lucid with the open source ati drivers and i noticed how much fglrx sucks with compiz.
    i mean all the desktop effects feel way smoother with the oss drivers.
    is there any good reason for fglrx to have such a bad performance?
    there is a good reason that fglrx sucks. it's described in launchpad bug 351186. over a year ago Felix Kuehlig wrote a comment related to this bug and posts a patch for 9.04 that still works.
    i have created a ppa you can find here



    install, restart, smile. dont forget to advice synaptic not to overwrite this with a new version.

    Comment


    • You can find a ppa here, had the same problem and fix it for myself:

      Comment


      • is this just the backclear patch or is there something else he does?

        Comment


        • Originally posted by chronniff View Post
          is this just the backclear patch or is there something else he does?
          Yes, ist the no backclear, original written/posted by Felix Kuehling (i think amd). This patch had worked for me in 9.04 and 9.10. When i install lucid, the same poor behavior came back, this time without a ppa. So i took the patch, apply it and build. This fix my problems with lucid and my 4890. Its the same path aon the same sources. Only the version nr. xorg-server... has grown. You can say old patch in new version. Nothing less or more.

          Comment


          • [QUOTE=agaida;120307]I've lost a thing. The no backclear patch is the successor to the no backfill patch. The no backfill patch is developed first for issues related to intel graphics and had some glitches. After that came no backclear. i guess, it may be that the patch prevent some other failure, but i am not sure.

            Comment


            • The no-backfill patch has been around for years and was included in most distro releases since without it most drivers showed the slow-unminimize problem. The patch was *removed* in the run-up to the spring 2009 releases because it caused problems with the new Intel drivers (previous window contents re-appearing, flagged as a security risk), and at that point the slow-unminimize problems re-appeared on drivers which were using XAA.

              Felix created the backclear patch (strictly speaking I guess it's "no-backfill but clear instead of filling") which addressed the slow-unminimize problem *and* the problem with re-appearing window contents on Intel hardware.
              Test signature

              Comment


              • Originally posted by bridgman View Post
                The no-backfill patch has been around for years and was included in most distro releases since without it most drivers showed the slow-unminimize problem. The patch was *removed* in the run-up to the spring 2009 releases because it caused problems with the new Intel drivers (previous window contents re-appearing, flagged as a security risk), and at that point the slow-unminimize problems re-appeared on drivers which were using XAA.

                Felix created the backclear patch (strictly speaking I guess it's "no-backfill but clear instead of filling") which addressed the slow-unminimize problem *and* the problem with re-appearing window contents on Intel hardware.
                The window content also re-appears on amd/ati hardware unfortunately.

                Comment


                • Interesting - hadn't heard that before. Is that only with the no-backfill patch or is it happening with backclear as well ?
                  Test signature

                  Comment


                  • Originally posted by bridgman View Post
                    Interesting - hadn't heard that before. Is that only with the no-backfill patch or is it happening with backclear as well ?
                    Ohh reading your post again from before, I see there exists two different patches. Well the content reappears with the no-backfill patch. Didn't knew there existed a patch which adressed both problems. Thx!

                    Comment


                    • Yeah, the backclear patch fixes the slowdown without introducing the old-content problem. There have been a few reports about memory leaks but they seem to have had other causes. There was also a report about something in the KDE suite actually relying on the backfill and so not drawing properly with no-backfill or backclear, but I didn't hear anything more about it.

                      Once we get the new 2D acceleration implemented in fglrx the patch shouldn't be required, although I hate calling that a solution -- it will just mean that there will be a large and normally wasted copy happening all the time, but all the drivers will accelerate it enough that everyone will live with it.
                      Test signature

                      Comment

                      Working...
                      X