Announcement

Collapse
No announcement yet.

AMD Catalyst 9.8 Preview

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

  • #11
    Hopefully.

    Btw, the Windows 9.8 drivers are already up on akamai.net and downloadable (for over a day now), even though there's no official announcement yet. I hope that:

    https://a248.e.akamai.net/f/674/9206...x86.x86_64.run

    will become active soon too

    Comment


    • #12
      Originally posted by d2kx View Post
      Remember it's only two months until Ubuntu 9.10 which uses Linux 2.6.31 and they'll want to support that from the beginning.
      Ubuntu just needs to use a patched kernel that still exports find_task_by_vpid

      Comment


      • #13
        Originally posted by ObiWan View Post
        Ubuntu just needs to use a patched kernel that still exports find_task_by_vpid
        Maybe... Doing that would give an interesting sign to the rest of the community though. As in, that distro maintainers can override kernel developers' decisions on kernel development. (strictly speaking this already happened at least once, eg Debian vs radeon microcode)

        Comment


        • #14
          Originally posted by nanonyme View Post
          Maybe... Doing that would give an interesting sign to the rest of the community though. As in, that distro maintainers can override kernel developers' decisions on kernel development. (strictly speaking this already happened at least once, eg Debian vs radeon microcode)
          What? Distro maintainers have been patching and modifying the kernel forever - that's their job!

          Comment


          • #15
            Originally posted by BlackStar View Post
            What? Distro maintainers have been patching and modifying the kernel forever - that's their job!
            It most definitely isn't the job of distro maintainers to have an opinion on where kernel development should head. If it was, they should be kernel developers. Fixing bugs is one thing to but re-exporting symbols means they disagree with where Linux kernel developers think the kernel should be going. I'm not sure I consider that a very good sign.

            Comment


            • #16
              Originally posted by nanonyme View Post
              It most definitely isn't the job of distro maintainers to have an opinion on where kernel development should head. If it was, they should be kernel developers. Fixing bugs is one thing to but re-exporting symbols means they disagree with where Linux kernel developers think the kernel should be going. I'm not sure I consider that a very good sign.
              In a perfect world, this makes sense. However, we don't live in a perfect world and no distro maintainer will let a significant number of systems break if he can help it.

              It's the maintainer's job to smooth things over and make sure the distro will work for the largest amount of users. This might involve mean patching the kernel (all distros); it might involve pulling out-of-tree branches (Fedora, I'm looking at you); it most certainly doesn't mean sitting back and enjoying the carnage when widely-used software stops working for one reason or another.

              I don't see this as a bad thing. The maintainer frees the kernel devs from the burden of supporting legacy software. Sooner or later, the legacy software will either be upgraded or it will become too costly to maintain and will be dropped (see Arch and fglrx).

              Comment


              • #17
                Originally posted by nanonyme View Post
                It most definitely isn't the job of distro maintainers to have an opinion on where kernel development should head. If it was, they should be kernel developers. Fixing bugs is one thing to but re-exporting symbols means they disagree with where Linux kernel developers think the kernel should be going. I'm not sure I consider that a very good sign.
                I remember reading on lkml the developers themselves say that distros are encouraged to change the kernel however they see fit. Upstream kernel does not deal with distro issues when it can avoid it. It's the distro's job to modify it and produce their own flair of the kernel. And they consider this a "Good Thing". Upstream is the "vanilla" flavor and it's not intended to be suitable for every one.

                Comment


                • #18
                  its already downloadable, but still not announced

                  Comment


                  • #19
                    Originally posted by nanonyme View Post
                    That note about the primitive restart sounds a bit funky. If that list of extensions actually is getting in as new stuff and they get the support for two new Linux versions, I'd probably be impressed if I still used the closed drivers.
                    Not really - it's probably something that won't concern most people (in other words, that bit on primitive restart isn't very funky), and actually might make things cleaner elsewhere. It's just a natural progression away from the whole client state enable/disable.

                    I'll definitely be looking forward to the glsl 1.40 support.

                    Comment


                    • #20
                      Originally posted by Dinth View Post
                      its already downloadable, but still not announced
                      Wut? Vherr?

                      Comment

                      Working...
                      X