Page 1 of 5 123 ... LastLast
Results 1 to 10 of 53

Thread: Radeon vs. RadeonHD Drivers In H1'08

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,093

    Default Radeon vs. RadeonHD Drivers In H1'08

    Phoronix: Radeon vs. RadeonHD Drivers In H1'08

    For Linux distribution vendors, right now is proving to be an awkward time for them as they decide which ATI driver will ship as the default choice in their spring distribution refresh. The problem used to be whether to ship a binary-only driver in the distribution in order to provide "out of the box" support for all available graphics hardware, but on the ATI/AMD side the software distributors are now facing the challenge of which open-source driver they should call the de facto standard. In this article we are briefly looking at the matter of the xf86-video-ati vs. xf86-video-radeonhd drivers, the highly political issue of AtomBIOS, and what some of the popular Linux distributions are deciding to use this spring.

    http://www.phoronix.com/vr.php?view=12052

  2. #2
    Join Date
    Mar 2008
    Posts
    2

    Default

    On the NVIDIA side, distribution vendors may soon find themselves in a similar boat choosing between the official xf86-video-ati 2D driver and the reverse-engineered Nouveau driver, which will be capable of both open-source 2D and 3D support.
    That should be the nv driver?

    Still a nice article. Thank you. I enjoy following Radeon development with Phoronix articles.

  3. #3

    Default

    Quote Originally Posted by LauriM View Post
    That should be the nv driver?

    Still a nice article. Thank you. I enjoy following Radeon development with Phoronix articles.

    Oops, yeah. Fixed, thanks

  4. #4
    Join Date
    Jul 2007
    Posts
    30

    Default

    Quote Originally Posted by phoronix View Post
    Phoronix: Radeon vs. RadeonHD Drivers In H1'08

    For Linux distribution vendors, right now is proving to be an awkward time for them as they decide which ATI driver will ship as the default choice in their spring distribution refresh. The problem used to be whether to ship a binary-only driver in the distribution in order to provide "out of the box" support for all available graphics hardware, but on the ATI/AMD side the software distributors are now facing the challenge of which open-source driver they should call the de facto standard. In this article we are briefly looking at the matter of the xf86-video-ati vs. xf86-video-radeonhd drivers, the highly political issue of AtomBIOS, and what some of the popular Linux distributions are deciding to use this spring.

    http://www.phoronix.com/vr.php?view=12052

    Right now I'm using the RadeonHD driver from their GIT repository on my home machine, but I'm not sure I'm happy with it so far. This is a Hardy Heron box too, so I'm sure I'm just running into all the usual teething problems with Beta software.

    I'm very willing to try both, and I'm actually looking to see if I can enable Compiz stuff on my X1600 Silent card.

    The only complaint I have right now is that I think my old Matrox G450 had crisper text, and with my bad eyes, that's a big issue. Not sure yet, and I haven't had time to play. It could just be my font choices right now.

    I'd love to see an article which tests both drivers on an R500 GPU to see how the performance and features compare.

    John

  5. #5
    Join Date
    Dec 2007
    Location
    Merida
    Posts
    1,104

    Default

    Yeah, a comparison is in order now. Maybe even compare them to fglrx in the near future.

  6. #6
    Join Date
    Jan 2008
    Posts
    138

    Default Adding support for r500/r600 to radeon permanently complicates code

    If you keep adding support to new cards in the same driver (radeon), it's going to make the driver slower even for the old cards due to the penalty of card-specific if statements. So it would be better from a performance p.o.v. to have a new driver like radeonhd. What's even more sad is that once someone indroduces support for r500/r600 into the radeon driver, no one will take the time to remove that support if it becomes superfluous, and were stuck with two drivers forever and a split tester base.

    Also, AtomBIOS sounds like just an excuse for AMD to not provide documentation. Furthermore, if you have a bug in AtomBIOS, you can't fix it unless you re-flash the card which would be dangerous.
    Last edited by stan; 03-19-2008 at 12:43 PM.

  7. #7
    Join Date
    Sep 2007
    Posts
    158

    Default

    Quote Originally Posted by stan View Post
    Also, AtomBIOS sounds like just an excuse for AMD to not provide documentation. Furthermore, if you have a bug in AtomBIOS, you can't fix it unless you re-flash the card which would be dangerous.
    It's the same problem as with the bad bioses on some old laptops with an i810 (you cannot use the display native resolution using the straight bios of the card). Really not a good situation to be in, so relying on the bios is a bad thing.

  8. #8
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote Originally Posted by stan View Post
    If you keep adding support to new cards in the same driver (radeon), it's going to make the driver slower even for the old cards due to the penalty of card-specific if statements. So it would be better from a performance p.o.v. to have a new driver like radeonhd.
    Here's the issue -- only the modesetting hardware changed between 4xx and 5xx. The acceleration hardware is largely unchanged, so the same code generally runs on both 3xx/4xx and 5xx parts.

    Quote Originally Posted by stan View Post
    Also, AtomBIOS sounds like just an excuse for AMD to not provide documentation.
    Sure, but we already provided the documentation

    We are providing complete documentation for what the registers do, and in some cases are creating new docs which explain how the pieces fit together. What we were hoping not to have to provide is the "set this register to 0x7... set that register to 0x0015fe2" level of detail since that was already coded and heavily tested in AtomBIOS.

    Quote Originally Posted by stan View Post
    Furthermore, if you have a bug in AtomBIOS, you can't fix it unless you re-flash the card which would be dangerous.
    One of the design criteria for AtomBIOS was the ability for the driver to over-ride any table with a newer version if required. We have been using AtomBIOS for the Windows drivers for a few years now and have never had to patch a table, but the mechanism is there.

    Quote Originally Posted by remm View Post
    It's the same problem as with the bad bioses on some old laptops with an i810 (you cannot use the display native resolution using the straight bios of the card). Really not a good situation to be in, so relying on the bios is a bad thing.
    Actually, that's not the case with AtomBIOS. We don't restrict you to specific modes. There is a traditional VBE / BIOS layer running on top of AtomBIOS which does have a fixed mode table, but that only affects VBE calls.
    Last edited by bridgman; 03-19-2008 at 02:37 PM.

  9. #9
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    326

    Default

    Quote Originally Posted by bridgman View Post
    Here's the issue -- only the modesetting hardware changed between 4xx and 5xx. The acceleration hardware is largely unchanged, so the same code generally runs on both 3xx/4xx and 5xx parts.
    With an emphasis on "generally".

    Quote Originally Posted by bridgman View Post
    Sure, but we already provided the documentation
    Partly. As far as i can remember, none of the PLL registers have ever been made public. Also, with both drivers now supporting RV620/635, the documentation for that still is not available. Since radeon fully depends on atombios (but hasn't much of a clue of what happens underneath), is there no more need for this information now?

    Quote Originally Posted by bridgman View Post
    We are providing complete documentation for what the registers do, and in some cases are creating new docs which explain how the pieces fit together. What we were hoping not to have to provide is the "set this register to 0x7... set that register to 0x0015fe2" level of detail since that was already coded and heavily tested in AtomBIOS.
    So AtomBIOS means that you do not ever have to bother with providing actual programming information?

    One of the design criteria for AtomBIOS was the ability for the driver to over-ride any table with a newer version if required. We have been using AtomBIOS for the Windows drivers for a few years now and have never had to patch a table, but the mechanism is there.
    Given that ATI doesn't want people to flash the BIOSes of their cards, it is rather hard to get patched tables out to people. In that light, it is probably just Not Done to patch any tables.

    Luckily the hardware is quite resilient, and i'm sure the windows/fglrx driver are full of workarounds like this: http://gitweb.freedesktop.org/?p=xor...t;h=10e7636c02

    Actually, that's not the case with AtomBIOS. We don't restrict you to specific modes. There is a traditional VBE / BIOS layer running on top of AtomBIOS which does have a fixed mode table, but that only affects VBE calls.
    It does restrict things which real code would not restrict. The choice between PAL or NTSC is largely dependant on what is available in AtomBIOS.

  10. #10
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    Quote Originally Posted by libv View Post
    Luckily the hardware is quite resilient, and i'm sure the windows/fglrx driver are full of workarounds like this: http://gitweb.freedesktop.org/?p=xor...t;h=10e7636c02
    This is to workaround the fact that we only use atom for external tmds chips on r4xx cards, the rest uses the old code.

Posting Permissions

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