Announcement

Collapse
No announcement yet.

My horrible experience with ATI

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

  • #31
    Originally posted by mtippett View Post
    The official support for kernels is more or less settling into the distribution release cycle for us. It means that we may skip restabilizing for a kernel if there are not distros targetting that kernel. For example, Karmic is targetting 2.6.31, and so our work is primarily focused on that kernel (targetted at Karmic's release).
    I understand that AMD is free to choose what they are going to support. I still find it a bit offensive that they choose to go so much un Ubuntu's terms. Fedora 11 (which I use) has Linux 2.6.29, which Catalyst doesn't support, despite the fact that even 2.6.30 is already available. Sounds also like we won't be getting Catalyst in the July release, either

    Luckily I have the free drivers. Some would certainly like to use OpenGL software on Fedora 11, too.

    Comment


    • #32
      Originally posted by muep View Post
      I understand that AMD is free to choose what they are going to support. I still find it a bit offensive that they choose to go so much un Ubuntu's terms. Fedora 11 (which I use) has Linux 2.6.29, which Catalyst doesn't support, despite the fact that even 2.6.30 is already available. Sounds also like we won't be getting Catalyst in the July release, either

      Luckily I have the free drivers. Some would certainly like to use OpenGL software on Fedora 11, too.
      Our supported distributions are primarily driven by direct requirements, ie: distributions that are used by the first level companies that buy our chips. This settles down to the 4 distros mentioned before.

      It is not on Ubuntu's terms. If Red Hat (RHEL) or SuSE (SLE) move to a new kernel earlier, then we move earlier. It just happens that there are typically Ubuntu releases earlier than SuSE or Red Hat. Note that Red Hat suggest us to not focus on Fedora as an incubator for RHEL, Novell suggested openSUSE as the incubator for SLE.

      As mentioned before, new X versions and new kernel versions will be targetted for the next supported distribution that picks them up. The kernel has the source based KCL which should empower any reasonably kernel-literate developer to patch. PM me if there are any functions that are not fully understood and we can update the doxygen comments. Remember that the engineers in my team are graphics driver domain experts, not the-rest-of-the-kernel experts. It costs us just as much to investigate and understand the kernel changes and how they affect the driver.

      Regards,

      Matthew

      Comment


      • #33
        Just my 2 cents.

        What should do those people that have fglrx support removed
        and therefore, can`t use newer Linux distributions with fglrx
        and also free driver doesn`t support them.

        Shouldn`t cards that are diched from fglrx support, be prepared for support in free drivers?
        I am just narrowing attention to those customers "in between".

        Not saying that peak of development shouldn`t be for newest cards.
        If new-released card is supported right away on release, we would have
        better user experience all the way.

        Sorry for my conclusion about turning users to beta testers,
        I realize now that AMD made enormous shift toward and made a big effort to supporting its Linux users.

        Anyway, GNU/Linux is a community - and during whole lifetime
        of a product i was fully available as an user for testing and testing and testing more, just to give my contribution to AMD efforts
        so I suggest to AMD to harnest that power of users, Digg to any
        user report came from site, etc and use those who want to do testing.

        I just posted my message out of honestly disbelieve that somewhat older
        graphics should be ditched from support this fast because AMD
        should be carefull with integrated graphics users.
        We are not power users of AMD graphics (yet we can aspire to insert some more powerfull graphics later) but we choosed AMD _platform_ as a whole.

        Comment


        • #34
          Originally posted by Markore View Post
          What should do those people that have fglrx support removed and therefore, can`t use newer Linux distributions with fglrx and also free driver doesn`t support them.
          With the specific exception of 3D apps requiring high levels of GL support, I believe all of the GPUs and usage scenarios were already supported as well as or better than fglrx before the parts were dropped from fglrx. For 3D-intensive users we recommended that they stay with their existing distro release until the open source driver framework catches up with their needs.

          If you see any other cases where products or usage scenarios are not supported by the open drivers, please let us know. Analog tv outputs are still causing trouble, but AFAIK everything else is supported.

          Originally posted by Markore View Post
          Shouldn`t cards that are diched from fglrx support, be prepared for support in free drivers? I am just narrowing attention to those customers "in between".
          Yes, I believe that is already the case. If you're not seeing that please let us know.

          Originally posted by Markore View Post
          Not saying that peak of development shouldn`t be for newest cards. If new-released card is supported right away on release, we would have better user experience all the way.
          The focus for fglrx is more on new parts (which makes sense, it's our launch vehicle for new products) but the focus for the open source drivers has primarily been on older parts. We're doing a push right now to get basic 6xx/7xx 3D running since the key community developers are focusing on adding features for older GPUs so there's nobody else to work on it, but in general the open source driver effort has gone at least as much into older parts as into newer ones.

          Originally posted by Markore View Post
          Sorry for my conclusion about turning users to beta testers, I realize now that AMD made enormous shift toward and made a big effort to supporting its Linux users.
          Thanks

          Originally posted by Markore View Post
          Anyway, GNU/Linux is a community - and during whole lifetime of a product i was fully available as an user for testing and testing and testing more, just to give my contribution to AMD efforts so I suggest to AMD to harnest that power of users, Digg to any user report came from site, etc and use those who want to do testing.
          Typical user reports are actually very difficult to use effectively other than as a way of pointing out areas where we may want to do more testing or documentation. In cases where we find users posting highly useable reports -- providing enough information to let an in-house developer quickly reproduce the problem -- we do try to invite those users into the beta test program so we can feed their findings directly back into the development process. There are practical limits to the number of people we can work with that way, so we certainly don't ask every good reporter we see.

          The problem is that a lot of user reports are more along the lines of "I installed distro X, then I replaced components Y and Z, then I installed 13 different drivers and edited a bunch of files, then I installed fglrx and it didn't work, you guys suck". I'm obviously exaggerating a bit here, but you get the idea. The chances of us duplicating that user's system configuration is pretty much zero, and in cases where we know the same driver and hardware work on a stock system it's hard to do anything but suggest a fresh install (which is usually not well received).

          When we ask for problems to be reproduced on a vanilla install of a distro we support it's not because we only care about those users, it's that reproducing the problem on a system we can duplicate in house is the only way our developers have a chance of doing anything about the problem.

          Originally posted by Markore View Post
          I just posted my message out of honestly disbelieve that somewhat older graphics should be ditched from support this fast because AMD should be carefull with integrated graphics users. We are not power users of AMD graphics (yet we can aspire to insert some more powerfull graphics later) but we choosed AMD _platform_ as a whole.
          For the record, I probably should mention that the open drivers already do a good job of supporting the typical usage scenarios of integrated graphics users. The cases where we have unhappy IGP users right now are generally where they are trying to do more than a typical IGP user, including gaming or other 3D-intensive apps. In those cases the open drivers aren't completely up to the task yet, but for the more common IGP usage scenarios I really do believe the open drivers are at least as good as fglrx was at the time we dropped support for the 3xx-5xx cores.

          Anyways, I do appreciate your feedback. We can't always make everybody happy immediately (I don't think any vendor is doing that yet) but we can at least influence future priorities.

          Thanks,
          John
          Last edited by bridgman; 07-19-2009, 02:57 PM.

          Comment


          • #35
            Originally posted by mtippett View Post
            The kernel compatability layer (KCL) is in source form, and users are able to look at the kernel functions and update as needed. If there are comments that are missing that do not communicate the intent of a function sufficiently for a developer to adapt to a new kernel, then please PM a question for a KCL function to me.

            Very rarely does a new kernel trigger an architectural change in the binary part of the driver, so realistically the community is at the same level of opportunity as the developers that report to me in updating to a new kernel.

            You have the kernel source, you have the KCL source. If the KCL function isn't clear, tell me and I will get the doxygen comments updated.
            The KCL is not the problem. This can be an is handled by the community. But when problems occour with the binary blob like with 2.6.28 and above
            Code:
            [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_close] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7fd783efe000,handle:0xf0940000
            then it should be handled faster by ATI/AMD.

            Comment


            • #36
              Hi. most time people posting only about there problems. I just want to say im an happy AMD/ATI customer ( since over 10 years ) without problems with the fglrx and thanks John and Matthew for an nice work and obviously all people working on the ATI Drivers ( Open and Closed Source ).

              PS. I hope we get maybe an present for Christmas called XvBA

              Comment


              • #37
                Originally posted by Nille View Post
                PS. I hope we get maybe an present for Christmas called XvBA
                LOL, you still believe in Santa Claus, do you?

                Comment


                • #38
                  Originally posted by monraaf View Post
                  LOL, you still believe in Santa Claus, do you?
                  Im confident that we get it early or later.

                  Comment


                  • #39
                    I'm sure that they must beta test these alpha quality drivers, but AMD does have a point in variances between linux distros w/various kernel and X.org versions running along with all of the distro specific patches applied.

                    OTOH there seem to be an ungodly number of bugs in the X.org catalyst drivers, some of which require system reboot which should NEVER happen, e.g. video playback after awake from sleep ALWAYS locks up at least X.org if not the entire system. (I am w/o a 2nd machine -to attempt to ssh in and verify this ATM.) Then there are the random screen corruption problems which are at least workaroundable by forcing a screen refresh.

                    I just keep hoping month after fruitless month that something awful will happen at AMD and they'll actually release a quality driver by mistake.

                    [EDIT]
                    It's kind of funny, in this case I'm actually holding out hope for the OSS drivers to be of higher quality than the vendor provided propietary one... (OSS drivers IME have serious problems for years and years, and I'd hazard that GPU drivers are some of the most difficult to write... or at least for GPUs that have any sort of decent functional capabilities...)
                    [/EDIT]
                    Last edited by cutterjohn; 07-21-2009, 01:11 PM.

                    Comment


                    • #40
                      @mtippett

                      If patching fglrx drivers is so easy, why don't provide OFFICIAL patches? That is common for Nvidia drivers too, i have got a full collection of em...

                      Comment


                      • #41
                        Originally posted by Kano View Post
                        @mtippett

                        If patching fglrx drivers is so easy, why don't provide OFFICIAL patches? That is common for Nvidia drivers too, i have got a full collection of em...
                        Simply because we don't plan for support of a new kernel until we are approaching the release of a distro-support update. Our OFFICIAL support comes out as part of the driver release. Depending on the requisite changes you may see support for a kernel earlier, but it definitely won't be announced or implied as a higher level of support.

                        The 2.6.29 and 2.6.30 kernels have had quite a bit of impacting changes that have mean non-trivial changes. For AC/DC power switching there is still work that needs to be done.

                        Nvidia has a different approach. I would expect that the NV approach is unofficial and unsupported patches that are posted as a convenience.

                        Regards,

                        Matthew

                        Comment


                        • #42
                          I understand that 2.6.29+ needs more changes, but there has been a long rc phase for 2.6.29 (beginning in january) and also 2.6.29 has been out since 20-Feb-2009 which was 4 (!) month before 9-6. Wouldnt you call that extremely slow to adopt those changes? Nv has 4 official drivers which do not require a single patch for 2.6.31 and one "stable" driver that needs one little patch.

                          Comment


                          • #43
                            Originally posted by Kano View Post
                            I understand that 2.6.29+ needs more changes, but there has been a long rc phase for 2.6.29 (beginning in january) and also 2.6.29 has been out since 20-Feb-2009 which was 4 (!) month before 9-6. Wouldnt you call that extremely slow to adopt those changes? Nv has 4 official drivers which do not require a single patch for 2.6.31 and one "stable" driver that needs one little patch.
                            By our stated policy, it hasn't been slow. 1) No supported distribution has updated to 2.6.29 or later so we don't need to start until closer to the distro updates and 2) the changes needed a non-trivial.

                            Slow is a relative term. Slower than you like, yes. Faster than distro-updates, no.

                            We know the state of the NV drivers, it is unlikely that the "2.6.31" support is complete, AC/DC switching for example. We have plans in place to ensure that the work is complete - or at least clearly documented.

                            Matt

                            Comment


                            • #44
                              Well Ubuntu karmic has 2.6.31 rc3 already, if you support U then you would need an update really soon. I don't think it was reasonable to give U a special driver for last bigger change just in time for release. It is certainly better when it is tested longer.
                              Last edited by Kano; 07-22-2009, 10:56 AM.

                              Comment


                              • #45
                                Wouldn't be better to ditch KCL and use (open-source) DRM instead? That way fglrx could support KMS also.

                                Comment

                                Working...
                                X