Announcement

Collapse
No announcement yet.

Radeon vs. RadeonHD Fighting Continues

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

  • #51
    Originally posted by bugmenot View Post
    Hm.
    Is radeon going to implement support for R600 if 3d is working?
    Yes, radeon will implement all the 3D-engine-based acceleration.
    And why can't the radeon guys just perfecting the support until R500 or ask the radeonhd guys if they could help them if they're bored instead of "taking them their work away"?
    Could you explain a bit further? There's only a tiny bit of stuff missing from the r5xx support, and it's all pretty trivial/non-important (color controls for textured video, dynamic powersaving), and also missing from radeonhd, too.

    Also, agd5f *has* helped radeonhd. airlied and I haven't, but that doesn't mean that we're being evil.
    Radeonhd works so great here and there are different patched like powersaving and hdmi audio that do not exist for radeon, would be bad if radeonhd would disappear only because one man made a bad decision.
    Thanks.
    HDMI patches for r6xx+ are going to be ported over as soon as I have spare time and nothing more important like, say, Mesa work. :3 (Or class!)
    The powersaving patches are woefully undertested IMO, and IIRC they are to be used "at one's own risk."
    Also, like I said earlier, radeonhd isn't going anywhere. It's only been dropped from one build script, that's all.

    Comment


    • #52
      Most of the work in radeon these days is making use of kernel modesetting and memory management (GEM) across all the supported ASICs.

      I don't believe anyone is sitting around bored.
      Test signature

      Comment


      • #53
        Originally posted by MostAwesomeDude View Post
        The powersaving patches are woefully undertested IMO, and IIRC they are to be used "at one's own risk."
        Indeed.

        FWIW, radeon already has the DynamicClockGating hooks for AtomBIOS, which is the only PM feature that's remotely reasonable to assume safe.

        Frankly, I don't see the harm in having two separate drivers developing in parallel until the dust around KMS settles down. Beyond that, well, we'll just have to see.

        Comment


        • #54
          Originally posted by MostAwesomeDude View Post
          Yes, radeon will implement all the 3D-engine-based acceleration.
          Last i heard, this is not where AMD wants to go. But maybe Mr Bridgman can give the ATI view of the world.

          Comment


          • #55
            Originally posted by bridgman View Post
            Honestly, if it were that simple this would have been resolved a long time ago. When we started the project there were two native modesetting drivers and teams - Avivo (public, reverse engineered) and a private effort led by Dave written using NDA information. Dave had contacted us about releasing his driver but we didn't really have enough of an open source plan at the time to give him any kind of quick answer, so that project more or less died.

            Both groups agreed to wind down their native modesetting work in favour of a new atombios-based driver initially written by Novell. When radeonhd came out as another native modesetting driver things got heated very quickly. The obvious argument from the existing driver project teams was that if the new driver was not going to be atombios-based then there was no justification for getting rid of avivo in the first place.

            In other words, everyone knew radeonhd was going to be a fork but that was ok since the goal was to get an atombios-based driver. Once radeonhd was released as a native modesetting driver rather than being atombios-based, it stopped being "a blessed fork" and things started to get ugly. The radeon and avivo developers were still looking forward to an atombios-based implementation and so implemented atombios-based modesetting in radeon.

            We eventually got atombios-based modesetting in radeonhd (and a nice implementation at that) but by then the radeon and avivo developers were quite happy with the radeon implementation and saw no need to change.

            And that's where we are today.
            Many people have a very different view of how things played out.

            Comment


            • #56
              Originally posted by MostAwesomeDude View Post
              Yes, radeon will implement all the 3D-engine-based acceleration.

              Could you explain a bit further? There's only a tiny bit of stuff missing from the r5xx support, and it's all pretty trivial/non-important (color controls for textured video, dynamic powersaving), and also missing from radeonhd, too.

              Also, agd5f *has* helped radeonhd. airlied and I haven't, but that doesn't mean that we're being evil.

              HDMI patches for r6xx+ are going to be ported over as soon as I have spare time and nothing more important like, say, Mesa work. :3 (Or class!)
              The powersaving patches are woefully undertested IMO, and IIRC they are to be used "at one's own risk."
              Also, like I said earlier, radeonhd isn't going anywhere. It's only been dropped from one build script, that's all.
              I see it in that way: radeonhd was created in order to build a driver for R500+. Why did radeon even try to support these chips too, only because it is possible? I think the radeon guys should have seen that there will be two drivers and that that is never good. Now we have two good drivers and that makes no sense. If R600 3d is working both drivers will try to support these chips and this is a waste of resources. And radeon starts to port over the patches and the other way round. *This is just stupid.*
              Why not let radeonhd support R500+ / R600+ and the radeon guys should implement something like a powersaving infrastructure in X which can be used by all drivers for changing the powerstates automatically or can be used via an interface with which one could set them without restating X?

              The job of the radeonhd devs is to create a working driver. They did it. Why can't to radeon guys spend their time more useful for other things, X for example has some room for improvement. Why have they to do the duplicated work?

              Comment


              • #57
                Originally posted by bugmenot View Post
                The job of the radeonhd devs is to create a working driver. They did it. Why can't to radeon guys spend their time more useful for other things, X for example has some room for improvement. Why have they to do the duplicated work?
                The funny thing being that for my 780G chipset, the RadeonHD driver can't seem to get my screen to work worth a crap -- bad constant flickering, off center image, missing mouse cursor, etc. -- but the radeon driver works perfectly.

                Welcome to Open Source, dude. We duplicate a lot of stuff. Because that's how you get good software. We have multiple Free Software/Open Source kernels, We have multiple desktop environments. Multiple word processors. Multiple everything, really. And the Free Software ecosystem is better for it.

                Competition is good. For example, it lets developers try out radically different approaches to solving a problem (like with radeon vs radeonhd) and determine which one is best. The alternative would be to just make a decision and have no way to find out if it was the right one. RadeonHD has taken work from Radeon, and vice versa. Without both projects existing, it is entirely reasonable to assume that we might not have a driver as far along as either of them.

                Comment


                • #58
                  My two pence:
                  Since radeon is afaik a true FOSS-effort, I'd say nobody can tell the developers what they should be working on, except their employers if they have such.
                  I, for one, am very glad for their work, since imho they have produced the better driver.

                  Comment


                  • #59
                    Originally posted by elanthis View Post
                    Welcome to Open Source, dude. We duplicate a lot of stuff. Because that's how you get good software.
                    You should have a BIG asterdisk beside that statement. Duplication is OK if you have enough qualified people that can effectively code the solution. When the numbers of qualified developers is small the exact opposite happens, progress slows from lack of manpower to effectively put out cutting edge support. You end up with a few small featured projects that may excel in one area but losses out in another. You end up getting the software equivalent of a All-in-one printer. Sure it can scan, print and fax, just don't expect it to do a top of the line job at any one task when compared to dedicated solutions. The FOSS world is saturated with incomplete and abandoned projects because of it.

                    Comment


                    • #60
                      Originally posted by elanthis View Post
                      The funny thing being that for my 780G chipset, the RadeonHD driver can't seem to get my screen to work worth a crap -- bad constant flickering, off center image, missing mouse cursor, etc. -- but the radeon driver works perfectly.
                      Ah, I have a 780G chipset too, and here both drivers work. (though radeon crashed the whole computer while trying to rotate, did not try with radonhd) Did you report a bug to the radeonhd devs?

                      Welcome to Open Source, dude. We duplicate a lot of stuff. Because that's how you get good software. We have multiple Free Software/Open Source kernels, We have multiple desktop environments. Multiple word processors. Multiple everything, really. And the Free Software ecosystem is better for it. Competition is good.
                      Yes, there are some benefits. But there are also bad sides: If radeonhd does not work for you, you *maybe* report no bug to radeonhd, just because radeon works. And if a newbie tries to install a linux distri with radeonhd by default and gets no X because he has your hardware config and you did not report the bug because you know how to switch to radeon. So it *can* be bad for the end user experience.
                      [...] and determine which one is best.
                      By dropping radeonhd from the default build script?

                      Some hardware works good with both drivers, other hardware better with radeonhd, other hardware only with radeon. If there was only one driver there would be a better chance that your hardware configuration works.
                      (because potential bugs are more likely reported)

                      Comment

                      Working...
                      X