Announcement

Collapse
No announcement yet.

Radeon vs. RadeonHD Drivers In H1'08

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

  • #16
    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".

    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?

    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.

    Comment


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

      Comment


      • #18
        Originally posted by agd5f View Post
        Unfortunately, acceleration is the hardest thing to get working correctly in a video driver, especially the 3D engine (used by textured video and EXA render accel). Once radeonhd gets similar acceleration features, they will be in the same boat.
        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.

        Comment


        • #19
          Originally posted by agd5f View Post
          This is to workaround the fact that we only use atom for external tmds chips on r4xx cards, the rest uses the old code.
          So you're not using atombios to the full extent possible there? Just for those bits where you cannot be bothered?

          Comment


          • #20
            The answer is simple.

            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?

            Comment


            • #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
              http://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
                  http://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; 03-19-2008, 06:34 PM.

                            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