Announcement

Collapse
No announcement yet.

Radeon vs. RadeonHD Drivers In H1'08

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

  • #21
    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.
    Michael Larabel
    https://www.michaellarabel.com/

    Comment


    • #22
      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?

      Comment


      • #23
        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.
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #24
          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.

          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.

          Comment


          • #25
            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.

            Comment


            • #26
              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.

              Comment


              • #27
                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.

                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?

                Comment


                • #28
                  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.

                  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.

                  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.

                  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.

                  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; 19 March 2008, 06:34 PM.
                  Test signature

                  Comment


                  • #29
                    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.

                    Comment


                    • #30
                      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.

                      Comment

                      Working...
                      X