Announcement

Collapse
No announcement yet.

Drivers for linux are rubbish

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

  • Originally posted by hotnikkelz View Post
    adamk:
    I wasn't being technical when i said 'fail', forgive me (was using gaming terms). I thought i understood what was going on, but your post confused me a bit. What are these open drivers you speak ok? I was under the impression that fglrx was half open/half proprietary? and of course ATI linux 10.5 was fully proprietary.
    No, fglrx is fully closed source. The drivers that Ubuntu recommends are simply repackaged versions of the 10.4 driver from AMD/ATI. They *are* fglrx. There is no real distinction between the drivers Ubuntu recommends and the one you downloaded (other than the downloaded ones being slightly newer and packaged for Ubuntu already).

    That's the only drivers i know of and tried. What drivers do stock ubuntu come with that enables my card to work well with compiz straight out of the box.
    The ones straight out of the box. That's as pretty clear as I can make it. The open source drivers, which are used in Ubuntu by default, will run compiz and do not suffer from the same 2D performance issues you were experiencing.

    Shouldn't installing a recent ATI driver give me even better performance?
    Not at 2D operations, particularly composited ones.

    I have a feeling i will need ATI over stock ubuntu when it's time to game.
    Depends on the game, but that is likely the case, yes.

    Adam

    Comment


    • I wanted to clarify this statement, but this stupid site won't let me edit my post:

      The open source drivers, which are used in Ubuntu by default, will run compiz and do not suffer from the same 2D performance issues you were experiencing.
      This should be true for all radeons up to the HD4950.

      Adam

      Comment


      • bridgman: Yeah, there was a new Intel driver which relied on the downloaded data to overwrite old data in newly allocated memory buffers. Nothing wrong with that AFAIK (presumably it was done as a performance optimization) but it interacted badly with the no-backfill patch, allowing users to see old screen info which potentially could have been from another user's session.

        The problem was flagged as a security issue and removing the patch was the most expedient way to close it. The result was that any driver running XAA acceleration became very slow when performing certain operations. Felix implemented the backclear patch which performed the same function as no-backfill but also added code to clear out the destination buffer, eliminating the security hole on Intel GPUs while still providing good performance on XAA drivers.

        When the 10.6 driver comes out, check the release notes to see if the new 2D acceleration code is enabled by default. If so, give that driver a try and it should address some of the problems you are seeing.
        Hmm, that's interesting. Let me see if follow u..
        Is 2D acceleration code DISABLED by default in 10.5? If that's the case...why? and wouldn't another solution to my problem be to just edit something that enables 2D acceleration?
        So, XAA controls 2D acceleration, and X server is tied in with that (in layman terms), which is why a prepatched x server will solve my problem as well right?
        And where did fglxr go 'wrong' where all this is concerned?

        Comment


        • The new 2D accel code from amd is a little unstable right now (a few graphical glitches) - basically it's not ready. Nor has it been officially announced by AMD (someone violated their NDA and leaked info about it). So it's not yet enabled by default.

          Comment


          • adamk:
            Ah interesting.I guess i'll be using Ubuntu's default for the while until i'm sure ATI's proprietary will give me the results i want. Now i'm not longer surprised that fglrx and 10.5 both lagged, cuz there's not much difference between them. I also assume, that the same 'fix' will probably work for either version. THank you for the clarification

            mirv:
            By new 2d accel code are you referring to the one that 10.6 is going to have? I assume there's a 10.6 beta out already? or are you referring to the 2D accel code in 10.5? I was asking if in 10.5 that code is disabled by default and if so how to enable it. If that code is unstable then it doesn't really matter

            Comment


            • Originally posted by hotnikkelz View Post
              adamk:
              Ah interesting.I guess i'll be using Ubuntu's default for the while until i'm sure ATI's proprietary will give me the results i want. Now i'm not longer surprised that fglrx and 10.5 both lagged, cuz there's not much difference between them. I also assume, that the same 'fix' will probably work for either version. THank you for the clarification

              mirv:
              By new 2d accel code are you referring to the one that 10.6 is going to have? I assume there's a 10.6 beta out already? or are you referring to the 2D accel code in 10.5? I was asking if in 10.5 that code is disabled by default and if so how to enable it. If that code is unstable then it doesn't really matter
              No 10.6 beta out - but the 2D acceleration code has been present for a little while and can be enabled with:
              aticonfig --set-pcs-str=DDX,Direct2DAccel,TRUE
              or disabled with:
              aticonfig --del-pcs-key=DDX,Direct2DAccel

              (as root, or sudo, or whatever takes your fancy)

              Consider yourself warned however that it will have some graphical glitches!

              Comment


              • Originally posted by hotnikkelz View Post
                Is 2D acceleration code DISABLED by default in 10.5? If that's the case...why? and wouldn't another solution to my problem be to just edit something that enables 2D acceleration?

                So, XAA controls 2D acceleration, and X server is tied in with that (in layman terms), which is why a prepatched x server will solve my problem as well right?

                And where did fglxr go 'wrong' where all this is concerned?
                2D acceleration is enabled by default, but it uses the standard XAA interface which does not happen to accelerate the specific download operation required when running an unpatched X server with a compositor and unminimizing a window etc...

                Patching the X server eliminates the download when unminimizing -- the download is normally wasted anyways because the downloaded data usually gets over-written immediately after the transfer. Unfortunately the patch has been gone for a year or so and a few more programs have started relying on the downloaded data. As an example, if you are running newer versions of KDE you will see small black squares briefly appearing when running with a patched X server, corresponding to areas where the downloaded data would have been used.

                The only thing fglrx does "wrong" here is that it uses the XAA interface for acceleration. The upcoming 2D acceleration code replaces the XAA standard with a new and larger set of functions, including one which accelerates the download operation.

                As others have posted, the currently shipping drivers include in-development versions of the new acceleration code, but since the new code has not been completed we disable it by default. Future versions of the driver (probably this month's release) will include newer versions of the code and at some point it will be considered ready to enable by default. Until then your options are (a) use a patched X server, (b) use the open source drivers which are enabled by default when installing Lucid, (c) enable the work-in-process accel code in the 10.5 driver and see how it works on your system, (d) live with the delays.

                Given that the new accel code is likely to appear in the next regular driver release I would probably go with option (b).

                Comment


                • ohhh ok, i understand much more now *phew*
                  Thanks you guys. Must have taken you guys a while to learn the ins and outs of how these things work lol, i'm only now tinkering with linux since it's going to take over the world

                  I have one final question i believe. If fglrx (which is basically compiled 10.4 drivers right?) whose 2D accel uses XAA and thus is unable to accelerate the download, what does 10.5's 2D accel code use and do you know how it differs with the even newer 2D accel code in 10.6.
                  And yes i will definitely go with option B, time flies fast, I'll be trying to learn the basics of ubuntu during that time

                  Comment


                  • Just to clear up. There are two drivers for your card currently available and being developed:

                    FGLRX = Catalyst = proprietary = closed-source = ATi official driver (that's the 10.5 thing you had to download)

                    and

                    Open Source driver = kernel + Mesa + radeon = "radeon driver" = free driver (that's the thing that is installed on Ubuntu by default)

                    If you are going to be playing lots of WINE stuff, you'll need the proprietary drivers. They are very optimized and have latest whizbang, but as you've seen, they have their issues with 2d and video.

                    For most regular use (including desktop effects and some native gaming), the open source drivers are a good choice.

                    Comment


                    • "fglrx" is the internal name for the Catalyst Linux Edition proprietary driver, and the string appears in a number of file names and messages. Just two names for the same thing.

                      Note that the fglrx driver installed by Ubuntu is slightly different from the final 10.4 driver available at amd.com - we gave the Ubuntu folks a pre-release version of what would eventually become the 10.4 driver in order to meet their internal schedules. All three versions (Ubuntu, final 10.4 and 10.5) use XAA by default, and the XAA code is the same other than bug fixes, so unless you are forcing on the unreleased "new 2D" code you should see the same behaviour on all three.

                      If you force the unreleased "new 2D" code on (recognizing that it is *not* ready for normal use yet) then 10.5 is probably quite a bit better than 10.4, but still not good enough for us to enable it by default.

                      Comment

                      Working...
                      X