Announcement

Collapse
No announcement yet.

R800 3D mesa driver is shortly before release

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

  • I think that the major problem is that ATi had a LOT of catching up to do, as they had not only one, but several generations out there for which there was almost no open-source support.

    I'm pretty sure that timely support is what they are planning for future chips. It didn't work out for Evergreen, since they started writing the OSS drivers 3 years too late -- something that the current developers are not responsible for.

    Comment


    • Originally posted by allquixotic View Post
      As a proud owner of the most expensive ATI desktop video card in existence, the HD5970, I can say this: I appreciate ATI's commitment to open source, and I appreciate their commitment to high performance 3d graphics. But I want to see your executives in the next board meeting dutifully jotting down on their notepads that they need to work on reducing the publicly-visible open source driver development time (the time between official product launch date and open source driver availability). This issue needs high level attention. ATI's leaders need to know that this is a major concern for a lot of people. Management needs to push this through...
      Already happening, and has been happening for a while. It was part of the original plan we presented to the execs back in 2007.

      If you look at the timelines for the last few generations (HW launch to 3D support at the level of previous generations) you get something like :

      5xx - mid-2005 launch, late 2008 support => 3-1/2 yrs

      6xx - mid 2007 launch, mid-late 2009 support => 2-1/2 yrs

      7xx - mid 2008 launch, mid-late 2009 support => 1-1/2 yrs

      EG - late 2009 launch, RSN support => less than 1 yr

      Fusion - being planned now

      next gen discrete - being planned now

      In the meantime the driver also picked up all kinds of nice additions like EXA & textured video accel, GL 2 support including flow control, kernel modesetting, etc...

      Comment


      • I can't edit, but after verifying some dates the timeline is probably closer to :

        5xx - 3 yrs

        6xx - 2 yrs

        7xx - 1 yr

        EG - <1yr

        Comment


        • One thing that may not be obvious is that Alex and Richard worked on adding core driver features (finishing the transition to KMS, adding GL 2 support and flow control etc..) in the fall of 2009 rather than starting immediately on Evergreen support.

          I still believe that was the right thing to do but there are obviously good arguments both ways, particularly if you own an Evergreen GPU.

          Comment


          • Originally posted by bridgman View Post
            EG - <1yr
            Is that a promise? That leaves about a month and a half left to release it.

            Do you have any idea about how long we'll have to wait for Fusion? It's supposed to be coming out around Sept. isn't it?

            Comment


            • Originally posted by smitty3268 View Post
              Is that a promise? That leaves about a month and a half left to release it.

              Do you have any idea about how long we'll have to wait for Fusion? It's supposed to be coming out around Sept. isn't it?
              Edit: Hmm, now I'm seeing 1st half 2011, so I guess it's further out than i thought.

              Comment


              • That part that bridgman leaves off is that the eventual plan is for them to be all caught up, no longer need to spend dev time adding support for released products or massive new driver architecture, and be able to start pushing driver support for new parts before they hit the shelves.

                Granted, unless they push it well over 6 months in advance, you'll still be stuck with shiny new Linux distro install CDs that don't have the requisite support, since both the Linux kernel and now X.org have taken the user-hostile approach of breaking the driver API (and ABI) every release. Nothing says "cares about users" like forcing them to upgrade their entire OS and application stack (and then get the whole new slew of bugs and arbitrary UI changes the desktop stacks seem to get every six months) just to get support for a new piece of hardware.

                Comment


                • Originally posted by elanthis View Post
                  Nothing says "cares about users" like forcing them to upgrade their entire OS and application stack (and then get the whole new slew of bugs and arbitrary UI changes the desktop stacks seem to get every six months) just to get support for a new piece of hardware.
                  Usually you can just upgrade the kernel, libdrm, xorg and mesa to the latest stable or development versions and have the rest of the distribution work fine with no user visible changes.

                  Often the best way is to tell the package manager to install those packages (and only those) from the distribution development branch.

                  It's however best to upgrade all those components together to avoid possible weird issues, suboptimal performance or missing features.

                  Comment


                  • Originally posted by elanthis View Post
                    That part that bridgman leaves off is that the eventual plan is for them to be all caught up, no longer need to spend dev time adding support for released products or massive new driver architecture, and be able to start pushing driver support for new parts before they hit the shelves.

                    Granted, unless they push it well over 6 months in advance, you'll still be stuck with shiny new Linux distro install CDs that don't have the requisite support, since both the Linux kernel and now X.org have taken the user-hostile approach of breaking the driver API (and ABI) every release. Nothing says "cares about users" like forcing them to upgrade their entire OS and application stack (and then get the whole new slew of bugs and arbitrary UI changes the desktop stacks seem to get every six months) just to get support for a new piece of hardware.
                    All you need to replace is the kernel, though, and mesa + DDX driver. That's not really any more intrusive than getting a binary driver. Besides, it's much better than the alternative of having a system like windows where your stuck with legacy decisions made in the DOS days and can't ever change because everyone else relies on it.

                    Comment


                    • Originally posted by Agdr View Post
                      Usually you can just upgrade the kernel, libdrm, xorg and mesa to the latest stable or development versions and have the rest of the distribution work fine with no user visible changes.
                      And note that the interfaces exposed by those components as a whole (the non-GPU-specific kernel ABI, OpenGL and the X11 API) are very stable and there is full commitment to keeping compatibility forever for them.

                      Some core kernel developers even run ancient distributions on some of their test machines to ensure this is the case.

                      Comment

                      Working...
                      X