Announcement

Collapse
No announcement yet.

Ubuntu Has Another Special ATI Catalyst Driver?

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

  • #16
    Originally posted by bulletxt View Post
    I DON'T WANT FGLRX, IT CLAIMS TO BE SOMETHING IT ISN'T: A WORKING DRIVER FOR MY GPU.

    Am I going against the netiquette?
    no bashing fglrx is a phoronix valid rule...

    you are simple not an phoronix member if you don't bash fglrx....

    only the amd payed guys can not join this fun.......

    but bridgman if you read between the line very smart you can read a fglrx bash to because he is the opensource man of amd LOL

    so in the end the netiquette of phoronix is bashing fglrx or be kicket!

    Comment


    • #17
      Originally posted by raulromania View Post
      I switched over to win7 until everything get more efficient. I mean, there are a many thnigs which are under development to ensure a nice workflow.
      It will take a while to fully support all of the hardware its in my ACER 7740G (http://geizhals.at/eu/a497111.html) Hopefully lucid will do most of it.

      It is not the problem to the configure xorg.conf manually. The package scripts for karmic are broken for 10.1. So I gave up. Its not my cup of tea to give up so fast, but i dont want to waste so much time with configuring my system. You are using arch, right? Probably i will try it these days.
      Well, I had my headaches with making my Acer 5740g dualboot (even repairing windows7 boot record), and making the WiFi working for netinstall. Afterwards I needed downgrading Xorg and putting it on IgnorePkg. If that's achieved it's quite simple afterwards, installing the catalyst AUR package with makepkg and pacman -U. Also I had to add broadcom kernel module to load before tg3 to make the LAN working. I'm planning to create a howto about dualbooting on these great notebooks including the catalyst tricks and tips.

      Comment


      • #18
        I do not have dualboot. My Linux is completly removed - but hopefully not a long time. One important question kronius.

        What Hard disk drive is/was installed in your Notebook.
        In my Acer Aspire 7740G-434G64Mn (LX.PNX02.021) is a Western Digital Scorpio Blue 640GB, SATA II (WD6400BEVT) installed.

        The Power Management of the HD is very aggressive (60h).
        If you dont use a tool or hdparm and if the drive has nothing to do (idle), it parks the head a few times per minute. The Load Cycle Count (a S.M.A.R.T. value) of your HD will rise very fast and your HD can be f***** up in only one year or faster. Additionally it can be very annoying if you are in a room where it is dead silence.

        If you have a WD HD, check your S.M.A.R.T. values.
        I use CrystalDiskInfo under Win7.
        You can change AAM and APM values with it and make it start with your OS. I've shut down APM completly (FEh).
        If YOU (reader) are using a Linux/Unix OS check THIS.

        Comment


        • #19
          Originally posted by raulromania View Post
          I do not have dualboot. My Linux is completly removed - but hopefully not a long time. One important question kronius.

          What Hard disk drive is/was installed in your Notebook.
          In my Acer Aspire 7740G-434G64Mn (LX.PNX02.021) is a Western Digital Scorpio Blue 640GB, SATA II (WD6400BEVT) installed.

          The Power Management of the HD is very aggressive (60h).
          If you dont use a tool or hdparm and if the drive has nothing to do (idle), it parks the head a few times per minute. The Load Cycle Count (a S.M.A.R.T. value) of your HD will rise very fast and your HD can be f***** up in only one year or faster. Additionally it can be very annoying if you are in a room where it is dead silence.

          If you have a WD HD, check your S.M.A.R.T. values.
          I use CrystalDiskInfo under Win7.
          You can change AAM and APM values with it and make it start with your OS. I've shut down APM completly (FEh).
          If YOU (reader) are using a Linux/Unix OS check THIS.
          Thanks for the info! Arch has a so called storage-fixup created for that purpose. For now i have added a script that turns APM off as my HDD isnt included in the default config file of this thing, I will try to extend the arch based package's config file.

          Comment


          • #20
            "However, with Ubuntu now looking for people to test out the proprietary ATI driver and emailing Pulido for instructions, it looks like they're getting ready to roll out an unreleased Catalyst driver for Linux."

            No, this is the wrong conclusion to draw. We do not have updated ATI Catalyst drivers yet. The actual reason we're doing this testing is not so much for finding issues in the proprietary drivers themselves (they're pretty well tested before they get to us, and if we found bugs we couldn't fix them), but rather to detect regressions caused by changes elsewhere in the system, which only show up for users of proprietary drivers.

            For instance, last release we upgraded the proprietary drivers and at the time everything worked fine. Later on, towards the end of the development cycle, upstart and gdm2 were introduced, along with several boot speed improvements. In certain circumstances, these changes caused breakage for proprietary driver users. (For instance, the boot speed improvements that went in late in the cycle could cause X to attempt booting before dkms had finished building the kernel driver. We don't need dkms for the open source drivers, so the issues didn't affect them.)

            So, this effort is just geared to set up a weekly testing regimen throughout the development cycle, that will hopefully highlight regressions caused by changes in the underlying system at the point where those changes are made (we get plenty of random bug reports but these lack the indication of *when* the change went in causing the regression.) The purpose of this is to give us more power to solve these issues well before release, so we can ensure a smooth experience for proprietary driver users.

            Comment


            • #21
              Originally posted by Qaridarium View Post
              no bashing fglrx is a phoronix valid rule...

              you are simple not an phoronix member if you don't bash fglrx....

              only the amd payed guys can not join this fun.......

              but bridgman if you read between the line very smart you can read a fglrx bash to because he is the opensource man of amd LOL

              so in the end the netiquette of phoronix is bashing fglrx or be kicket!
              I wonder if AMD, internally, jokes about the unfortunate facts of fglrx too.

              Comment


              • #22
                Originally posted by damentz View Post
                I wonder if AMD, internally, jokes about the unfortunate facts of fglrx too.
                I'm sure they do, these are smart guys and they know the quality of the product they're putting out.

                Honestly, if AMD just put out a roadmap stating when they thought all the various problems with fglrx might be solved, that would be a good start. Right now it's like Flash - there are so many problems and no indication about whether AMD even intends to fix them, let alone whether it's under progress now or scheduled for 5 years later.

                Comment


                • #23
                  I'm quite sure the drivers don't have as many problems as people keep suggesting. I'll note that many will say "it's got so many problems, blah blah blah", but few actually state any problems, and of those that do, it's rarely a problem but rather a missing feature.
                  So I imagine AMD says dilligaf a lot.

                  Comment


                  • #24
                    Originally posted by mirv View Post
                    I'm quite sure the drivers don't have as many problems as people keep suggesting. I'll note that many will say "it's got so many problems, blah blah blah", but few actually state any problems, and of those that do, it's rarely a problem but rather a missing feature.
                    So I imagine AMD says dilligaf a lot.
                    You're right in that a lot of it is missing features rather than outright bugs.

                    What does fglrx need for people to take it seriously?

                    Video accelerated decoding needs to work, out of the box, with no fiddling and no errors. And no breaking when a new driver comes out each month.

                    xserver no-backfill. Need i say more?

                    Supporting new versions of x and the kernel in less than 6 months. Heck, nvidia is supporting this stuff before they're even released.

                    constant crashes when watching video. ok, this one might already be fixed, i haven't actually used fglrx in a while because the oss drivers are working better for me.

                    This is analogous to the Flash situation, to me. Flash mostly works, it's just that it does so rather poorly and there's no indication that things are going to get better any time soon.

                    Comment


                    • #25
                      Originally posted by smitty3268 View Post
                      You're right in that a lot of it is missing features rather than outright bugs.

                      What does fglrx need for people to take it seriously?

                      Video accelerated decoding needs to work, out of the box, with no fiddling and no errors. And no breaking when a new driver comes out each month.

                      xserver no-backfill. Need i say more?

                      Supporting new versions of x and the kernel in less than 6 months. Heck, nvidia is supporting this stuff before they're even released.

                      constant crashes when watching video. ok, this one might already be fixed, i haven't actually used fglrx in a while because the oss drivers are working better for me.

                      This is analogous to the Flash situation, to me. Flash mostly works, it's just that it does so rather poorly and there's no indication that things are going to get better any time soon.
                      Well for people to take it seriously, the 3D stuff needs to work. And it does. The "people" here most important are the workstation market - it has been said many times that this area is the target of fglrx.

                      Video accelerated decoding would be nice - but do bear in mind that AMD have never officially released it, and don't support it. So it's strictly something missing at the moment, albeit something that a good many would like.

                      xserver-backfill - yep, you'll need to say more (at least for me to understand). I can't remember too much about that as it was something that never affected me.

                      Not had a problem with video in a long time here. Used to have issues with xv (crashes typically), but it's worked fine for well over a year now (for me at any rate). Of course, I don't use much eye candy for my desktop (e16 user, occasionally e17) so I may well not encounter some of the problems that others have.

                      Comment


                      • #26
                        Originally posted by mirv View Post
                        Well for people to take it seriously, the 3D stuff needs to work. And it does. The "people" here most important are the workstation market - it has been said many times that this area is the target of fglrx.

                        Video accelerated decoding would be nice - but do bear in mind that AMD have never officially released it, and don't support it. So it's strictly something missing at the moment, albeit something that a good many would like.

                        xserver-backfill - yep, you'll need to say more (at least for me to understand). I can't remember too much about that as it was something that never affected me.

                        Not had a problem with video in a long time here. Used to have issues with xv (crashes typically), but it's worked fine for well over a year now (for me at any rate). Of course, I don't use much eye candy for my desktop (e16 user, occasionally e17) so I may well not encounter some of the problems that others have.
                        Yes, i know fglrx is targeted towards the workstations. That's my point, is that it sucks for the desktop linux usage i want to use it for. I'm sure that for their paying customers it's better, but I'm selfish and really don't care about them.

                        The xserver backfill thing was in response to terrible desktop performance the driver had when maximizing windows and doing other wm tasks. I'm not sure AMD ever even officially acknowledged the problem, but bridgman told users to apply the no-backfill patch to the xserver to fix it. Last i heard, it was still an issue for fglrx, and the xserver folks weren't going to accept it upstream because they viewed it as a hack to work around a fglrx-only bug that would end up affecting all the other drivers which already worked correctly. Never heard any more from amd besides applying that patch, and that they were "looking into it". That was probably a year ago now.

                        Comment


                        • #27
                          I'm not sure if I ever "officially acknowledged the problem" either (I'm not the official problem-acknowledger ) but we sure talked about it for a long time. Here's the background one more time :

                          1. The "no backfill" code had been shipping in most distributions for years in order to improve performance on all hardware - I think it was first added to Fedora then spread across to other distros as well. Looking back, we now know that all hardware needed the patch because all hardware ran with XAA acceleration at the time, and XAA did not accelerate the "backfill" (copying big chunks of data from video memory to system memory) which was required under certain conditions.

                          2. Somewhere in late 2008 / early 2009 a problem appeared using Intel hardware, resulting in (IIRC) previously used screen buffers re-appearing on the screen, which could contain sensitive data. Disabling the "no-backfill" code was found to eliminate this problem, so the "no backfill patch" was flagged as a security problem and removed from the next round of distro releases. This resulted in the delays you know about when running a compositor and unminimizing windows etc... on some hardware (mostly ours).

                          3. Much debate and finger-pointing ensued. In the end, it turned out that removing the long-standing "no-backfill" patch caused performance problems when running with XAA acceleration and compositing but not with EXA or other similar acceleration schemes. Note that since IGP parts use a common pool for system and video memory the copy can sometimes be "free" on that hardware but not on discrete GPUs.

                          4. The root cause seemed to be a discrepancy in the specs for X and related extensions, in the sense that a literal interpretation of the spec resulted in what many called non-intuitive behaviour, ie a large copy of data down to system memory, which was then promptly over-written and discarded. There seemed to be agreement on the problem, but it wasn't clear how to fix the problem other than making that largely redundant copy run faster, which apparently had come for free as drivers moved from XAA to other acceleration APIs.

                          4. As a short-term fix, Felix implemented a "no-backclear" patch (no-back*clear* rather than no-back*fill*) which returned performance to where it was when distros were all shipping no-backfill, but without the side-effects on Intel (and apparently other) hardware.

                          5. As a medium-term fix, the 2D acceleration API on fglrx is going to be changed to one which can accelerate the backfill operation, so we'll still be doing the redundant copy (just like all the other hardware vendors) but at least will be doing it quickly. This isn't a real solution, but it works for now and at least everyone will be dealing with the problem in the same way.

                          6. The real solution, if it ever happens, will involve some TBD changes to the X and extension specs to eliminate the largely wasted copy (maybe something similar to Felix's no-backclear patch), or maybe just to live with it and flag the backfill copy operation as a core function which needs to be accelerated (or at least fast) on all drivers.

                          Comment


                          • #28
                            Originally posted by raulromania View Post
                            It is not the problem to the configure xorg.conf manually. The package scripts for karmic are broken for 10.1. So I gave up. Its not my cup of tea to give up so fast, but i dont want to waste so much time with configuring my system. You are using arch, right? Probably i will try it these days.
                            Have a look at this thread. Takes no more than a minute, fglrx builds fine and works like a ch... ah... nevermind . Hope this will help you.

                            Comment


                            • #29
                              Originally posted by bridgman View Post
                              4. As a short-term fix, Felix implemented a "no-backclear" patch (no-back*clear* rather than no-back*fill*) which returned performance to where it was when distros were all shipping no-backfill, but without the side-effects on Intel (and apparently other) hardware.

                              5. As a medium-term fix, the 2D acceleration API on fglrx is going to be changed to one which can accelerate the backfill operation, so we'll still be doing the redundant copy (just like all the other hardware vendors) but at least will be doing it quickly. This isn't a real solution, but it works for now and at least everyone will be dealing with the problem in the same way.

                              6. The real solution, if it ever happens, will involve some TBD changes to the X and extension specs to eliminate the largely wasted copy (maybe something similar to Felix's no-backclear patch), or maybe just to live with it and flag the backfill copy operation as a core function which needs to be accelerated (or at least fast) on all drivers.
                              Is anyone actually working on that medium term fix, or is it on the roadmap to eventually be done in a few years? I ask because it's already been 1 year, and it doesn't seem like it would take that long to accelerate a single operation. Unless you mean you are switching the whole driver to use EXA? That could take a year. Otherwise, it seems like you are prioritizing this bug very, very low, and I don't think that you can seriously argue that fglrx is ready for "normal" desktop use if that's the case. Maybe AMD isn't even saying that, and they're saying that if you can get lucky and get it working then great, but don't expect any more than that.

                              Comment


                              • #30
                                Originally posted by smitty3268 View Post
                                Is anyone actually working on that medium term fix, or is it on the roadmap to eventually be done in a few years? I ask because it's already been 1 year, and it doesn't seem like it would take that long to accelerate a single operation. Unless you mean you are switching the whole driver to use EXA? That could take a year. Otherwise, it seems like you are prioritizing this bug very, very low, and I don't think that you can seriously argue that fglrx is ready for "normal" desktop use if that's the case. Maybe AMD isn't even saying that, and they're saying that if you can get lucky and get it working then great, but don't expect any more than that.

                                It's being worked on. That I think is the most I can write without getting into trouble.

                                Comment

                                Working...
                                X