Announcement

Collapse
No announcement yet.

AMD/ATI lost another Linux customer

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

  • #16
    Originally posted by m4rgin4l View Post
    I said that it doesn't look like it's going to change because:

    a) The software keeps changing (kernel, mesa, X, etc.),
    b) New hardware is being released
    That's what I don't understand. We've been dealing with those issues all this time, and in the last ~20 months have pretty much caught up after being out of open source graphics for ~7 years. Open source drivers don't get hit by changes in the underlying software because the developers making those changes can and do update the drivers at the same time - and keeping pace with new hardware introductions is much easier than catching up in the first place.

    Progress on the drivers has been pretty much what we said users should expect -- are you saying that you expected the release of specs to result in better, faster drivers "almost immediately" ? If so, I'm sorry but I don't believe that either we or the development community every said anything like that.

    If you're saying "I bought an ATI product a year ago because of the announcement about releasing programming specs, but I'm having trouble living with that decision because I really need full-featured 3D support on Fedora" that's a perfectly reasonable statement -- but that isn't how the thread started.

    Your original post said "What drove me to buy an ATI card was the news that they were going to publish the specifications and I thought that maybe for once a manufacturer understood how to interact with the community and that they were actually going to make some positive change in the Linux driver scene."

    Where do you think we have failed in that regard ?
    Last edited by bridgman; 07-31-2009, 01:45 PM.

    Comment


    • #17
      This thread makes me sad. Believe me though that I've seen equally as many people switch from Nvidia to ATI/AMD (I'm one of them) because Nvidia isn't as great as you make it seem.

      A few examples:
      The 71xx series of drivers is not receiving support anymore. That means users of everything Geforce2 and older are SOL when it comes to a stable driver. Nouveau crashes all the time and doesn't support any 3D.

      The 96xx series took 6 months to get support for Xserver 1.6. It's also likely getting too expensive to support and will be relegated to the waste bin.

      In a few years, the same thing will happen to the newer generation of cards.

      2D performance is much higher on the ATI/AMD OSS drivers. It's stable, doesn't crash, suspends properly, and offers tear-free Xv. KMS and DRI2 are here already, and Gallium3D will be here by next summer.

      Now, those features probably aren't foremost on your needs list, which means that you should've evaluated what the card and driver are capable of before purchasing. I'm as happy as a clam now on my R500 card which I bought one year ago. Tell me, what is it about fglrx that makes it unusable? I was on that driver before I transitioned to the OSS drivers once the support matured.

      As bridgman said, the driver team started from scratch on all the cards and have caught up now in all but the 3D for the R6xx/R7xx cards. In the next official release, they will be up to the previous gen level of support. The rate of progress now is fast enough that future generations of cards will be supported much faster than the R6xx/R7xx series is.
      Last edited by crumja; 07-31-2009, 01:42 PM.

      Comment


      • #18
        Originally posted by bridgman View Post
        OK, although I still don't understand the premise of the thread. Your original post said "What drove me to buy an ATI card was the news that they were going to publish the specifications and I thought that maybe for once a manufacturer understood how to interact with the community and that they were actually going to make some positive change in the Linux driver scene."

        What do you think we have failed to do in terms of interacting with the community etc.. ? Progress on the drivers has been pretty much in line with what we said users should expect -- are you saying that you expected the release of specs to result in better, faster drivers in a shorter period of time ? If so, I don't think any of the developers would have supported that view even 2 years ago.
        AMD hasn't failed at all. In terms of interaction with the community AMD did everything right (which is still surprising). The thing is that, at least for me, nothing have changed in the last year, I'm still dealing with a feature-less OSS driver and a non-working proprietary one.

        Anyway, I think there's no point in continuing arguing about this. This isn't helpful for anyone. Perhaps the only valuable piece of information that can be extracted from this thread is that Fedora users should stay away from the latest generation AMD cards, a fact that should be obvious for anyone willing to search through the forum.

        PS: Please refrain yourselves from suggesting that I should apply any of the patches that are publicly available to the Catalyst driver. Applying those patches is the manufacturer's job, not mine

        Comment


        • #19
          no, patching is the distris job. If your distri can't do it, look for one that does.

          gentoo is even more 'moving' than fedora - and there fglrx is not really a problem. The ebuilds include all patches needed. Sure, sometimes you have to get it from bugzilla - or do it yourself in the first days after a release - but it is easily done.

          Comment


          • #20
            Originally posted by crumja View Post
            This thread makes me sad. Believe me though that I've seen equally as many people switch from Nvidia to ATI/AMD (I'm one of them) because Nvidia isn't as great as you make it seem.

            A few examples:
            The 71xx series of drivers is not receiving support anymore. That means users of everything Geforce2 and older are SOL when it comes to a stable driver. Nouveau crashes all the time and doesn't support any 3D.

            The 96xx series took 6 months to get support for Xserver 1.6. It's also likely getting too expensive to support and will be relegated to the waste bin.

            In a few years, the same thing will happen to the newer generation of cards.

            2D performance is much higher on the ATI/AMD OSS drivers. It's stable, doesn't crash, suspends properly, and offers tear-free Xv. KMS and DRI2 are here already, and Gallium3D will be here by next summer.

            Now, those features probably aren't foremost on your needs list, which means that you should've evaluated what the card and driver are capable of before purchasing. I'm as happy as a clam now on my R500 card which I bought one year ago. Tell me, what is it about fglrx that makes it unusable? I was on that driver before I transitioned to the OSS drivers once the support matured.

            As bridgman said, the driver team started from scratch on all the cards and have caught up now in all but the 3D for the R6xx/R7xx cards. In the next official release, they will be up to the previous gen level of support. The rate of progress now is fast enough that future generations of cards will be supported much faster than the R6xx/R7xx series is.
            CRAP! So I'm screwed either way

            Anyway, I think you made a very good point. Maybe the next gen cards will be supported faster. In the meantime I have to stick with whatever works NOW.

            Thanks for the info.

            Comment


            • #21
              Originally posted by energyman View Post
              no, patching is the distris job. If your distri can't do it, look for one that does.

              gentoo is even more 'moving' than fedora - and there fglrx is not really a problem. The ebuilds include all patches needed. Sure, sometimes you have to get it from bugzilla - or do it yourself in the first days after a release - but it is easily done.
              Why patching to support the latest kernel (and the rest of the sw stack) is the distro's job? I'm willing to accept that for the OSS drivers, but not for the proprietary drivers.

              Comment


              • #22
                Originally posted by m4rgin4l View Post
                Why patching to support the latest kernel (and the rest of the sw stack) is the distro's job? I'm willing to accept that for the OSS drivers, but not for the proprietary drivers.
                I think iit is because each distro has its own policy for installing files.

                Comment


                • #23
                  Originally posted by doubledr View Post
                  I think iit is because each distro has its own policy for installing files.
                  That might be the case for the distro managed packages, but I was referring to the manufacturer provided package.

                  Also, Fedora does not include proprietary packages on its repos, so they wouldn't do it anyway

                  Comment


                  • #24
                    again, use a distri that puts the user first - like gentoo :P

                    Comment


                    • #25
                      Hey m4rgin4l, I'm one of the guys like you! But in my case, I bought a 3870 which doesnt allow me to play Team Fortress 2 in Linux (crashes when loading a map, right now flickering because ATi HDMI is used). I never entered a map. But I bought the 3870 because of AMDs step to release documentation. I could have bought a Geforce 8800GT at that time, but I wanted to support AMD.

                      In the first step, I justed wanted to tell you:
                      Are you taking part in OOS driver development? No? Then STFU!
                      But on the other hand: With buying an AMD card, you already supported them! So, your task is done! Now its their task to give you drivers for your platform.

                      But the main reason why I'm being so hard to AMD is, because you're right saying "They dont care about costumers!" Need a prove?
                      The so called "Themen-Woche" (Topic-Week) on planet3dnow: http://www.planet3dnow.de/vbulletin/...play.php?f=197
                      It was advertised with users can ask AMD, AMD answers! AMD did NOTHING!!!! Let me repeat: NOTHING!!! They totally blamed one of the biggest sites in Germany! Wanna see how to do it properly? Look at the Intel-Evening: http://www.planet3dnow.de/vbulletin/...play.php?f=198 They nearly answered everything! Last time, when they couldn't answer, they asked a spezialist at the company and gave the answer later.

                      AS a stock owner (yeah, I made that mistake, too), I wrote to AMD. The answer?
                      I will forward your email to the Director of our
                      product PR division. We will look into the matter and work to find a
                      solution to ensure all inquiries are addressed appropriately in the
                      future.
                      Well, thank you! How about apologizing to planet3dnow and making a REAL topic-week?

                      Overall: You're right! AMD doesn't take care about costumers, after they bought a card. Well.. yeah.. Wait! They supported a funny overclocking event (http://www.planet3dnow.de/vbulletin/blog.php?cp=8). Thanks AMD! Good Job and cheap advertisement for your superduperuberoverclockable CPUs, that can't compare at stock speed with Intels High-End-CPUs.

                      Sorry for being offtopic... But I needed to say this!

                      Comment


                      • #26
                        Originally posted by Hasenpfote View Post
                        I could have bought a Geforce 8800GT at that time, but I wanted to support AMD.
                        I find it funny how people can be so generous to a company that doesnt properly support your platform and yet not donate a dime to the various projects that make up that platform.

                        Comment


                        • #27
                          What the hell?

                          As a user of a Lenovo T500 with switchable graphics between the Intel 4500X chipset and an ATi 3650, I feel the need to add to this discussion. I can't believe we have an AMD employee here going on about "BLEEDING EDGE" software support. That is completely ridiculous. Let me say I am no open source crusader, I use the NVIDIA closed sourced drivers on other machines, and I wold also use fglrx IF IT WORKED. I respect that you have released documents on open source, but if you really wanted to effect changes quickly in the Linux community you would just release the source for fglrx for Linux, since it is obvious you need the open source community's help developing that buggy piece of shit, rather than forcing them to reverse engineer everything from scratch just to protect some kind of trade secrets, which are no longer really secrets anyway.

                          Since my machine uses many new components I am required to use these so-called bleeding edge kernels. The oldest kernel I can use to give me wireless support is 2.6.27, 2.6.28 supposedly works with it however it is buggy and I experienced some crashes. Additionally, the oldest kernel I can use to get proper support for my Intel chipset GPU with the new Intel drivers is a heavily patched version of 2.6.29, or preferably 2.6.30 (both of these also work great with the wireless, thank you!). Intel or NVIDIA do not send their employees to troll forums complaining about bleeding edge software, rather they actually work on supporting the current state of Linux software, and they do a fine job of it. Also the NVIDIA closed source drivers add support for these 'bleeding edge' kernels usually before they are even officially out.

                          Since, as you can see I use a laptop from a company you have obviously made a deal with to officially support, I find it rather insulting that your company has sent you here to make excuses, since you are not supporting it whatsoever in Linux. The fglrx driver serves almost no purpose that I can see, it is too buggy to use for any practical reason 3D drivers are used, even if I was willing to downgrade my kernel and forget about supporting the rest of my perfectly good hardware from companies which make working drivers available in a timely manner. It would be completely impractical for me to downgrade my entire system and compromise all my other hardware anyway, just to use drivers with buggy 3D rendering, buggy compositing and buggy video playback (oh right, all 3 reasons to even use a 3D card in the first place!)

                          I am sorry for the insulting and ranting tone of this post, but given you appear to be posting on behalf of AMD/ATi you are bringing out the worst of my feelings on this issue, and your stance is illogical and inexcusable.

                          Comment


                          • #28
                            Originally posted by bakou View Post
                            I am sorry for the insulting and ranting tone of this post, but given you appear to be posting on behalf of AMD/ATi you are bringing out the worst of my feelings on this issue, and your stance is illogical and inexcusable.
                            No worries. We're here to listen as well.

                            Originally posted by bakou View Post
                            As a user of a Lenovo T500 with switchable graphics between the Intel 4500X chipset and an ATi 3650, I feel the need to add to this discussion. I can't believe we have an AMD employee here going on about "BLEEDING EDGE" software support. That is completely ridiculous.
                            With respect, you are using "bleeding edge" differently from the way I do, and then getting mad about something I did not say. The recent Fedora releases have included code which is 3-6 months *ahead* of the upstream kernels -- that's what I'm calling bleeding edge, not the regular released kernels you need for new hardware support.

                            For distros with recent kernels from upstream I have been using the term "faster moving" (relative to the enterprise distros which make up most of our customer base) - if you don't think that is fair please let me know what you would consider appropriate.

                            Originally posted by bakou View Post
                            Let me say I am no open source crusader, I use the NVIDIA closed sourced drivers on other machines, and I wold also use fglrx IF IT WORKED. I respect that you have released documents on open source, but if you really wanted to effect changes quickly in the Linux community you would just release the source for fglrx for Linux, since it is obvious you need the open source community's help developing that buggy piece of shit, rather than forcing them to reverse engineer everything from scratch just to protect some kind of trade secrets, which are no longer really secrets anyway.
                            Please remember that AMD employees are the ones adding new hardware support to the open source drivers, with full access to the hardware design teams. Not sure where "reverse engineering" comes into it but maybe I'm missing your point.

                            Originally posted by bakou View Post
                            Since my machine uses many new components I am required to use these so-called bleeding edge kernels.
                            Again, you are the one using "bleeding edge" to refer to regular upstream kernels. I use it to refer to distros containing code which is *ahead* of the upstream.

                            Originally posted by bakou View Post
                            The oldest kernel I can use to give me wireless support is 2.6.27, 2.6.28 supposedly works with it however it is buggy and I experienced some crashes. Additionally, the oldest kernel I can use to get proper support for my Intel chipset GPU with the new Intel drivers is a heavily patched version of 2.6.29, or preferably 2.6.30 (both of these also work great with the wireless, thank you!).
                            We need to shorten the gap between new kernel release and support in fglrx in order to deal with the new hardware enablement issues you mention. Matthew and I have both said this multiple times, however we have also said that this will be a gradual effort, not something that happens overnight.

                            You don't have to wait for us, however -- the fglrx driver is written to an OS-neutral API, and the install package includes source code for a Kernel Compatibility Layer. This allows distro packagers or any interested third party to adapt the code to newer / different kernels without requiring modifications to the driver itself.

                            Originally posted by bakou View Post
                            Intel or NVIDIA do not send their employees to troll forums complaining about bleeding edge software, rather they actually work on supporting the current state of Linux software, and they do a fine job of it.
                            Neither do we. You are getting mad about things which we have not said or done. I might do it in the future though, so there's no harm in having a good rant just in case

                            The point I am trying to make (without success, apparently ) is that we are continuing to improve the open source and the proprietary drivers in parallel, however right now if you want to use the newest kernel versions then the open source drivers are your best bet.

                            Originally posted by bakou View Post
                            Also the NVIDIA closed source drivers add support for these 'bleeding edge' kernels usually before they are even officially out.
                            Our open source drivers also track the latest kernels and X servers, and they are used by developers *making* changes to the underlying code. The proprietary drivers do not, although I expect they will close the gap over time.

                            Originally posted by bakou View Post
                            Since, as you can see I use a laptop from a company you have obviously made a deal with to officially support, I find it rather insulting that your company has sent you here to make excuses, since you are not supporting it whatsoever in Linux. The fglrx driver serves almost no purpose that I can see, it is too buggy to use for any practical reason 3D drivers are used, even if I was willing to downgrade my kernel and forget about supporting the rest of my perfectly good hardware from companies which make working drivers available in a timely manner. It would be completely impractical for me to downgrade my entire system and compromise all my other hardware anyway, just to use drivers with buggy 3D rendering, buggy compositing and buggy video playback (oh right, all 3 reasons to even use a 3D card in the first place!)
                            What happens when you run the open source drivers with your kernel of choice ? I realize you won't have 3D HW acceleration yet, although we're getting pretty close, but display, 2D acceleration and video playback should be solid today. If they are not please let us know.
                            Last edited by bridgman; 08-01-2009, 02:27 AM.

                            Comment


                            • #29
                              Well you may be using bleeding edge to describe that, but the fact of the matter is fglrx (as far as I'm aware) doesn't support any kernels newer than .28, Which I believe was released around 8 months ago. I am a Gentoo user, I could downgrade but as I explained in my post it just would not make any sense in my situation, as my Intel card works great (I would LIKE to use the more powerful 3D capabilities of my ATi GPU!).

                              I have no desire to test the open source drivers until they have reliable 3D support for the same reason as above. My idea of good video playback is using mplayer OpenGL with direct rendering and shader based scaling (that is the only technology I am aware of on Linux that can compete with WinXP/Vista VMR, for example).

                              I didn't know it is the AMD engineers who are adding hardware support to the open source drivers, or working on them at all. In that case, wouldn't it be more a matter of cutting and pasting code from the fglrx driver then re engineering it to be more compatible with X protocols?

                              I have heard that the R600 drivers are just now starting to render triangles which is very good, but I don't think they are available for much public testing short of checking out drivers on git yourself (which can lead to some very messy situations...).

                              Why then do you continue to allocate resources to fglrx if you could just allocate them all to the open source effort which is what most people on Linux want anyway, and will probably result in a much better driver in the long run? I see that progress is being made, I just don't understand the logic behind the management of resources, especially in light of your response. Of course with collaboration between the OS community supporting new software and kernels will never be an issue, that is the whole point! That is why it will be better! Why pay your employees to constantly track kernel changes like nVidia when people are willing to do it for you? It makes a lot of sense to go totally open on Linux when there are an army of programmers willing to help. That is exactly why I am so frustrated with this situation where I am in limbo with two drivers where neither one is really useful, I'm sure they are both useful to people who have 2 year old PCs, but this is not how the world works.

                              Anyway Thank you for your response, I feel somewhat better about the situation now, my main concern is then why aren't more engineers and programmers from AMD working on the R600 open source effort rather than beating the dead horse that is fglrx on Linux (I know it works fine on Windows, that is probably why I'm logged in on Windows now lol)

                              Originally posted by bridgman View Post
                              No worries. We're here to listen as well



                              With respect, you are using "bleeding edge" differently from the way I do, and getting mad about things I did not say. The recent Fedora releases have had code that is 3-6 months *ahead* of the upstream kernels -- that's what I'm calling bleeding edge, not the regular released kernels you need for new hardware support.

                              For distros with recent kernels from upstream I have been using the term "faster moving" (relative to the enterprise distros which make up most of our customer base) - if you don't think that is fair please let me know what you would consider appropriate.



                              Please remember that AMD employees are the ones adding new hardware support to the open source drivers. Not sure where "reverse engineering" comes into it but maybe I'm missing your point.






                              We need to shorten the gap between new kernel / X server release and support in fglrx. Matthew and I have both said this multiple times. We have also said that this will be an incremental effort.



                              Neither do we. You are ssying things which we did not.



                              Our open source drivers also track the latest kernels and X servers, and they are used by developers *making* changes to the underlying code. The proprietary drivers do not, although I expect they will close the gap over time.



                              What happens when you run the open source drivers with your kernel of choice ? I realize you won't have 3D HW acceleration yet, although we're getting pretty close, but display, 2D acceleration and video playback should be solid today. If they are not please let us know.
                              Last edited by bakou; 08-01-2009, 02:49 AM.

                              Comment


                              • #30
                                Originally posted by bakou View Post
                                I have no desire to test the open source drivers until they have reliable 3D support for the same reason as above. My idea of good video playback is using mplayer OpenGL with direct rendering and shader based scaling (that is the only technology I am aware of on Linux that can compete with WinXP/Vista VMR, for example).
                                You might be surprised how well Xv works for you on the open source drivers. Same shader based scaling, plus lower CPU utilization and some additional filtering & colour space options. Not saying you should rip out your current setup on my say-so, but it might be worth checking what other users are saying.

                                Originally posted by bakou View Post
                                I didn't know it is the AMD engineers who are adding hardware support to the open source drivers, or working on them at all. In that case, wouldn't it be more a matter of cutting and pasting code from the fglrx driver then re engineering it to be more compatible with X protocols?
                                Just to keep us on the same page for names, fglrx is the "engineering" name for the Linux Catalyst driver, which in turn is basically an X/DRI driver that uses common code shared across multiple OSes.

                                The hardware layers of the Catalyst drivers (including fglrx) are perhaps 20x the size of the corresponding open source code, at least on the 3D side, and use a different underlying architecture. The extra size is what it takes for the last bit of performance and functionality. We were originally hoping to be able to leverage the hardware layers from the proprietary drivers but it turned out not to be practical because of the size and the architectural differences.

                                On the display/modesetting side, the open source drivers use AtomBIOS, which lets us run the same code used by the proprietary drivers. For functinality not covered by AtomBIOS we generally obtain pseudocode from the Catalyst driver teams and use that as an implementation guide.

                                The first round of new hardware support was done entirely by community developers while we were building an internal team, but the model that we are using today is that AMD developers focus on adding new hardware support which leaves community developers free to add features and functionality to the existing drivers. The lines are pretty fuzzy though -- community developers are already helping to troubleshoot and fix bugs in the 6xx/7xx 3D driver, and agd5f has been helping with the KMS/GEM/TTM implementation effort.

                                Originally posted by bakou View Post
                                I have heard that the R600 drivers are just now starting to render triangles which is very good, but I don't think they are available for much public testing short of checking out drivers on git yourself (which can lead to some very messy situations...).
                                First triangle was 9 months ago. Now we have most of the major functions working and are trying to hunt down a nagging problem with vertex buffers so that we can expand the testing. The back-to-front copy used in GLSwapBuffers is not yet HW accelerated but agd5f is working on that now. We are approaching the point where distro packagers should think about picking up the code but we're not there yet.

                                Originally posted by bakou View Post
                                Why then do you continue to allocate resources to fglrx if you could just allocate them all to the open source effort which is what most people on Linux want anyway, and will probably result in a much better driver in the long run? I see that progress is being made, I just don't understand the logic being the management of resources, especially in light of your response. Of course with collaboration between the OS community supporting new software and kernels will never be an issue, that is the whole point! That is exactly why I am so frustrated with this situation where I am in limbo with two drivers where neither one is really useful, I'm sure they are both useful to people who have 2 year old PCs, but this is not how the world works.
                                Simple. The fglrx driver is what we need for the professional workstation market. Over the last 18 months or so we have also started using it to deliver high end features to consumer users. I expect that most consumer users will be perfectly happy with the open source drivers, however.

                                We could have done all the development in secret and only announced when we were finished, but I think that would have taken longer and annoyed the community in the process. We wanted to hire developers who were familiar with the open source stack, and it seemed to make the most sense to have them keep working closely with the rest of the community. That meant you had to watch and suffer while we development took place rather than just being given the end product, but I still think this is the right way to proceed.

                                Originally posted by bakou View Post
                                Anyway Thank you for your response, I feel somewhat better about the situation now, my main concern is then why aren't more engineers and programmers from AMD working on the R600 open source effort rather than beating the dead horse that is fglrx on Linux (I know it works fine on Windows, that is probably why I'm logged in on Windows now lol)
                                The critical path items for the open source drivers have been (a) writing and releasing the programming docs, and (b) coming up to speed on the latest driver stack. I don't think adding more developers would have really made that much difference.

                                Our largest Linux market is still the professional workstation market, which is almost entirely based on enterprise distros and relatively stable hardware platforms. That's where fglrx comes from, and where it continues to be essential. As long as we are making a proprietary driver, we are also trying to use it as a vehicle to deliver neat new features to consumer users, such as MultiView and Crossfire.

                                I'm logged in on Windows too, but for different reasons -- after 2 years and a big box of scrapped hardware I still haven't found a Linux analog modem driver or standalone modem that can handle my crappy rural phone line ;(
                                Last edited by bridgman; 08-01-2009, 03:29 AM.

                                Comment

                                Working...
                                X