Page 3 of 6 FirstFirst 12345 ... LastLast
Results 21 to 30 of 53

Thread: Radeon vs. RadeonHD Drivers In H1'08

  1. #21

    Default

    Quote Originally Posted by ethana2 View Post
    Look at the benchmark comparison between them on phoronix, pick the fastest driver for the card, stabilize it, and ship it.

    Oh wait... don't tell me you didn't take bechmarks here.. I'm not seeing them. Am I missing something?
    If only it were that simple... Let alone those benchmarks are old and simply the basic EXA/XAA performance doesn't tell the whole story of the driver. That's like saying pick Windows over Linux if in Quake you find better frame-rates.

  2. #22
    Join Date
    Jun 2007
    Location
    The intarwebs
    Posts
    385

    Default

    Ok, it may be harder for the stable versions they'd be looking to ship, but now I'm curious.

    Could phoronix pull from today's code, compile both drivers and give OpenGL benchmarks?

  3. #23

    Default

    Quote Originally Posted by ethana2 View Post
    Ok, it may be harder for the stable versions they'd be looking to ship, but now I'm curious.

    Could phoronix pull from today's code, compile both drivers and give OpenGL benchmarks?
    No, they aren't at OpenGL stage yet.

  4. #24
    Join Date
    Dec 2007
    Posts
    2,404

    Default

    Quote Originally Posted by libv View Post
    This is quite wrong. Modesetting always has been and always will be the single hardest thing to get right. With modesetting the demands and varying configurations are endless.
    I would disagree, but if that's what you believe, that's all the more reason to use atombios. It's been debugged by our bios and driver teams extensively since that is what our binary drivers and bioses use.

    Quote Originally Posted by libv View Post
    When acceleration works on one close enough related family of hardware, it will pretty much work everywhere. The user will not go around and suddenly change the whole layout there.
    The user will try and spin the compiz cube with 10 eye candy plugins enabled or try playing stage 2 of some 3D game and wonder why the whole computer hangs.

  5. #25
    Join Date
    Jun 2007
    Location
    The intarwebs
    Posts
    385

    Default

    Oh.
    *sigh* I wish Ubuntu had bi-monthly driver updates or something. I'm on Hardy now pretty much just for the latest drivers for our three intel GPU's.

  6. #26
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    342

    Default

    Quote Originally Posted by agd5f View Post
    I would disagree, but if that's what you believe, that's all the more reason to use atombios. It's been debugged by our bios and driver teams extensively since that is what our binary drivers and bioses use.
    Tell that to all those r100-r400 users that complain about 6.8.0 being a regression for them compared to 6.7.0.

    The user will try and spin the compiz cube with 10 eye candy plugins enabled or try playing stage 2 of some 3D game and wonder why the whole computer hangs.
    And will then disable DRI and do real work. Also, this user will not be the only person hitting that case. Everyone else who uses the exact same driver stack and close enough hardware will experience exactly the same with a wide range of 3d using applications.

  7. #27
    Join Date
    Dec 2007
    Posts
    2,404

    Default

    Quote Originally Posted by libv View Post
    Tell that to all those r100-r400 users that complain about 6.8.0 being a regression for them compared to 6.7.0.
    There was no atombios support r1xx-r3xx. If you don't want new functionality, stick with the old driver.

    Quote Originally Posted by libv View Post
    And will then disable DRI and do real work. Also, this user will not be the only person hitting that case. Everyone else who uses the exact same driver stack and close enough hardware will experience exactly the same with a wide range of 3d using applications.
    Exactly. Acceleration is much harder get stable than modesetting. How many stable 3D drivers are there compared to drivers that can get a picture on the screen?

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

    Default

    Quote Originally Posted by libv View Post
    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?
    There's certainly still a need, but as long as you have the modesetting info under NDA *and* have a go-ahead to use it in an open source driver we're treating the release of 3d information as higher priority than getting the modesetting docs out to the public. On balance I think that is the right approach, but there are strong feelings both ways.

    Quote Originally Posted by libv View Post
    So AtomBIOS means that you do not ever have to bother with providing actual programming information?
    Depends on what you mean by "programming information". We don't see the need to document what value should be programmed into each register, since it is not necessarily the same from chip to chip or even board to board. We do see a need to get register specs into developers hands. We also see a need for more "overview"-type documentation to help developers get started, but we didn't have any of that at the start of the project (nobody knows that better than you ) and hoped to follow an implementation path (AtomBIOS commands) which didn't need that information at the start.

    Quote Originally Posted by libv View Post
    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.
    AtomBIOS table patching is a runtime event where the driver supplies the newer table contents, not a BIOS re-flash.

    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
    Yep -- the 4xx AtomBIOS definitely had some rough edges. It wasn't until the 5xx family where we started using AtomBIOS 100% in the production drivers.

    Quote Originally Posted by libv View Post
    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.
    Yep. That was a deliberate decision IIRC (specific boards only supposed to be used with specific TV standards) although I don't remember the reason off the top of my head.
    Last edited by bridgman; 03-19-2008 at 07:34 PM.

  9. #29
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by libv View Post
    Tell that to all those r100-r400 users that complain about 6.8.0 being a regression for them compared to 6.7.0.



    And will then disable DRI and do real work. Also, this user will not be the only person hitting that case. Everyone else who uses the exact same driver stack and
    close enough hardware will experience exactly the same with a wide range of 3d using applications.
    Most of the 6.7->6.8 regressions were purely to do with randr-1.2 support, and dropping zaphod (which I mostly put back since). We probably could have just called it version 7 and stated it wasn't going to work with current xorg.conf as well, but clearly without someone funding our work at the time, most distros wanted randr-1.2 working instead of zaphod and we listened to the majority. Since we both got jobs now, we have had more time to stabilise and add back things like zaphod.

    Maybe disabling DRI is an option for Novell in the future, but we have users who want to run compiz and I'm sure you have some Xgl lovers internally as well.

    Just switching off accel is going to be less and less a solution and we are going to have to put more and more time into fixing those sort of problems. We are in a better position to do this now than we have ever been before.

    Dave.

  10. #30
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by libv View Post
    This is quite wrong. Modesetting always has been and always will be the single hardest thing to get right. With modesetting the demands and varying configurations are endless.

    When acceleration works on one close enough related family of hardware, it will pretty much work everywhere. The user will not go around and suddenly change the whole layout there.
    You must not use any of the modern hardware I've worked with. Acceleration features on any modern hardware is never simple, modesetting is a lot lot lot easier.. Didn't you rip out the one useful acceleration feature for VIA hardware from unichrome (hw mpeg decoding). I think you need to actually do some accel work, copying it from radeon will make it easy as we will have debugged it already. We're nice like that.

    Dave.

Posting Permissions

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