Page 11 of 18 FirstFirst ... 910111213 ... LastLast
Results 101 to 110 of 176

Thread: R800 3D mesa driver is shortly before release

  1. #101
    Join Date
    Jun 2009
    Posts
    2,929

    Default

    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.

  2. #102
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    Quote 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...

  3. #103
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    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

  4. #104
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    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.

  5. #105
    Join Date
    Oct 2008
    Posts
    3,130

    Default

    Quote 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?

  6. #106
    Join Date
    Oct 2008
    Posts
    3,130

    Default

    Quote 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.

  7. #107
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    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.

  8. #108
    Join Date
    Jul 2010
    Posts
    46

    Default

    Quote 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.

  9. #109
    Join Date
    Oct 2008
    Posts
    3,130

    Default

    Quote 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.

  10. #110
    Join Date
    Jul 2010
    Posts
    46

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •