Announcement

Collapse
No announcement yet.

Classic Radeon Drivers Are On Their Deathbed

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

  • #11
    Originally posted by Nille View Post
    I dont think that the Gentoo bugtracker/forum are an good place for mesa/driver bugs
    What are you implying ? Gentoo is as serious as any other distrib...

    Comment


    • #12
      Originally posted by peapa View Post
      What are you implying ?
      An Distribution Bug Tracker is not an optimal place is for reporting Bugs.

      Originally posted by peapa View Post
      Gentoo is as serious as any other distrib...
      I said something else?

      Comment


      • #13
        I don't see any problem with pulling the carpet out from BSD/solaris. Its not like the current drivers *don't work*, it would just mean that if they want to continue advancing, they'll either have to fork, or get off their sorry asses and implement the requirements. It isn't like this move would cause their screens to go black...

        Comment


        • #14
          Originally posted by Nille View Post
          An Distribution Bug Tracker is not an optimal place is for reporting Bugs.
          Why?

          It sometimes is, it sometimes isn't.

          In theory, a project's bug tracker deals with bugs that are in upstream code, and distro bug tracker tracks bugs which are specific to a particular distro, either as a result of distro-specific patches, or because of some interaction the package has with other distro-provided software.

          In practice, you rarely know what the hell is wrong, you only notice the symptoms. Very often, project-led bug trackers will close bugs saying they can only be reproduced on specific distros and let the maintainers deal with it. Similarly, things that don't work for user A after a package upgrade using distro B turn out to be upstream bugs.

          Ideally, package maintainers and upstream developers should communicate and share such bugs. I believe that Gentoo devs (and Debian and RedHat, etc.) are rather good at doing this.

          Comment


          • #15
            Originally posted by kbios View Post
            As far as I undersand radeon and r200 will remain, right? Thanks
            Hopefully R100 driver as well because my Thinkpad T42 has the Radeon Mobility 7500 which does not really work quite that smoothly with DRI2/KMS. The only other option for this chipset would be either using vesa driver or losing acceleration for R100

            Comment


            • #16
              I believe the intent is to remove the DRI1 code paths, so R100/R200 would run with DRI2/KMS. If you are still finding issues with the KMS paths relative to UMS please make sure the relevent bug tickets on fdo are up to date.

              Comment


              • #17
                Support for r1xx (radeon 3D driver) and r2xx (r200 3d driver) will still exist, but support for UMS (DRI1) will be dropped. Dropping the DRI1 support will however, allow us to support tiling in r1xx/r2xx with KMS much easier which should bring KMS performance up to or above UMS.

                Comment


                • #18
                  Originally posted by agd5f View Post
                  Support for r1xx (radeon 3D driver) and r2xx (r200 3d driver) will still exist, but support for UMS (DRI1) will be dropped. Dropping the DRI1 support will however, allow us to support tiling in r1xx/r2xx with KMS much easier which should bring KMS performance up to or above UMS.
                  Thanks for that clarification. It's nice to get info directly from those doing the work.

                  Comment


                  • #19
                    Originally posted by halfmanhalfamazing View Post
                    Thanks for that clarification. It's nice to get info directly from those doing the work.
                    Absolutely agreed here, I love reading these.

                    Comment

                    Working...
                    X