Announcement

Collapse
No announcement yet.

Radeon vs. RadeonHD Fighting Continues

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

  • #31
    choices and freedom this is what FOSS is all about.
    imho even if all the developers worked together they wouldn't do a good job because they wouldn't get alone well, different philosophies, egos, etc that's why many people work on the same project but from different angles.

    they shouldn't had drop the radeonhd driver like that; they should have at least inform the developers not because they have to, but just for respect to the radeonhd developers.

    however xorg developers have the right to not include any code they don't want or like if they decide to do so. if you don't like it you can start your own xserver.

    Comment


    • #32
      Originally posted by seba View Post
      however xorg developers have the right to not include any code they don't want or like if they decide to do so. if you don't like it you can start your own xserver.
      Which at that point you might as well be using the blobs since that is basically what they are doing. 12 months down the road another foss attempt drama unfolds and then spins another offshoot, all at the same time and nobody is excelling, I can't blame Nvidia for keeping their blob, at least they can hold themselves accountable for issues and resolve them without having to endure a bloody soap opera.

      Comment


      • #33
        sad but true...but what can we do about it? i can't point a gun to the X devs so that they include the driver again :-D

        Comment


        • #34
          sad but true...but what can we do about it? i can't point a gun to the X devs so that they include the driver again :-D
          but you can take the code and change it.

          Comment


          • #35
            Okay, let's clear up a few things.

            1) radeonhd is *not* being "dropped from X.org". It's only been removed from a build script. It's still hosted on the same git repos, still has the same web space and wiki pages.

            2) While a lot of radeon developers (including me) feel that radeonhd is duplicated effort and does not bring anything interesting to the table, that does not mean that we are doing anything to sabotage their efforts, and in fact, radeonhd's internal 3D engine acceleration (EXA, Xv) is based directly on radeon's 3D engine code. Saying that radeon developers are trying to quash radeonhd is just silly. (Not to mention that nearly all of us are on both #radeon and #radeonhd on Freenode.)

            3) Much of the code that used to be in DDX drivers has moved out of those codebases, and into separate projects. All OpenGL stuff is in Mesa, most modesetting has been ported to KMS (although KMS won't be mainlined for a bit...) Fussing about differences between the two drivers is going to become increasingly pointless.

            4) There's no forking going on. Pure and simple.

            ~ C.

            Comment


            • #36
              :S I think it's definately news-worthy, albeit with a poor selection of words. Sensationalising a discussion with strong opinions into a "good old argument and flaming" seems a bit too far...

              Comment


              • #37
                'duplicate drivers' are just a reality. Look at the kernel. There are TONS of duplicate drivers. Old, trusted, stable, versus new, feature richer, different cards of the same class.

                But the real evil thing was the SILENT drop. Mr Stone just dropped rhd without informing anybody.

                That is just low.

                Comment


                • #38
                  Originally posted by d2kx View Post
                  sundown, if you're using EXA with RadeonHD, you'll need to enable Option "DRI" aswell for now.
                  You were right. I added that as an option and it worked. But I can visibly tell that radeon outperformed radeonhd when I turned compiz on. Besides radeon+glxgears has 2-3 times more FPS than radeonhd+glxgears.

                  Comment


                  • #39
                    Originally posted by MostAwesomeDude View Post
                    Okay, let's clear up a few things.

                    1) radeonhd is *not* being "dropped from X.org". It's only been removed from a build script. It's still hosted on the same git repos, still has the same web space and wiki pages.

                    2) While a lot of radeon developers (including me) feel that radeonhd is duplicated effort and does not bring anything interesting to the table, that does not mean that we are doing anything to sabotage their efforts, and in fact, radeonhd's internal 3D engine acceleration (EXA, Xv) is based directly on radeon's 3D engine code. Saying that radeon developers are trying to quash radeonhd is just silly. (Not to mention that nearly all of us are on both #radeon and #radeonhd on Freenode.)

                    3) Much of the code that used to be in DDX drivers has moved out of those codebases, and into separate projects. All OpenGL stuff is in Mesa, most modesetting has been ported to KMS (although KMS won't be mainlined for a bit...) Fussing about differences between the two drivers is going to become increasingly pointless.

                    4) There's no forking going on. Pure and simple.
                    ~ C.
                    1) it was dropped without consulting the parties involved, quite deliberately so. I wonder what i'll hear from daniels this time round when FOSDEM (which supersedes XDS now, and which never cost Xorg more than 500EUR ever) needs some funding help from the Xorg board again.

                    2) It is radeon that duplicated effort, the timeline of support in both drivers should tell you exactly that. There was always going to be some duplication on the r5xx as only the modesetting engine was exchanged there.

                    3) Good luck convincing linus on KMS, if even GEM is getting that much flack.

                    4) RadeonHD was forked by Redhat and alex deucher. There is no other way of putting it. If anyone is to be blamed for duplication of effort, then it's those people.

                    Comment


                    • #40
                      I'm not a X or driver developer (I'm just your average 15-year old game programmer ), I think RadeonHD should be default for R500+, while radeon should stick to the older cards.

                      Comment


                      • #41
                        Originally posted by libv View Post
                        1) it was dropped without consulting the parties involved, quite deliberately so. I wonder what i'll hear from daniels this time round when FOSDEM (which supersedes XDS now, and which never cost Xorg more than 500EUR ever) needs some funding help from the Xorg board again.

                        2) It is radeon that duplicated effort, the timeline of support in both drivers should tell you exactly that. There was always going to be some duplication on the r5xx as only the modesetting engine was exchanged there.

                        3) Good luck convincing linus on KMS, if even GEM is getting that much flack.

                        4) RadeonHD was forked by Redhat and alex deucher. There is no other way of putting it. If anyone is to be blamed for duplication of effort, then it's those people.
                        1) Yeah, this is true. On one hand, kind of a dick move. On the other hand, really not the end of the world; Ubuntu and Suse still ship radeonhd by default and autodetect with it before radeon IIRC, and I haven't heard any plans to change that. It's just a build script.

                        2) Don't be silly; all of us duplicated xf86-video-avivo. :3

                        In all seriousness, this is like saying that the nouveau project has duplicated the functionality of xf86-video-nv. Technically true, but not the reason for either project.

                        3) Yeah, Linus was a hard sell. I remember him cursing us out during Linux Plumbers. Basically, we all agreed about KMS and GEM:
                        - KMS is the way it should have been done in the first place
                        - Switching from TTM to GEM was silly since so much effort had been put into TTM, but Intel was already into it and nobody could really object since Alex and Dave had already figured out how to put GEM on top of TTM guts
                        - It's gonna be a rough transition, but it only needs to be done once
                        - All the DDXs need to have dual-compatibility, both pre-GEM/KMS and afterwards, and for Intel, GEM and KMS can be split

                        But yeah, he was not happy about it.

                        4) Well, um, I'm not really sure what to say. I don't think there's any commits in either repo which were cherry-picked from the other. There's some code in radeonhd which is from radeon originally, but I didn't really think there was any straight-out forking...

                        ~ C.

                        Comment


                        • #42
                          Forking is whenever a project splits from a main development trunk and works independent ( aka patches/commits into one repo doesn't affect the other repo ). Forking is not about "mindset" but about "forked repos".

                          Comment


                          • #43
                            the most important thing here is that AMD still hasn't released full documentation after all this time. this is the worst thing. these internal stuff between radeon and radeonhd are just gossip to fill websites threads. nothing will change to the end user.

                            so yes, the real fighting is me, a user like a bunch out there vs AMD and:
                            1: their eternal shitty fglrx driver. it's worse than Star Wars, it never seems to end.
                            2: their totally incomplete documentation release

                            that's all I have to say about this sh*t.
                            Last edited by bulletxt; 10-22-2008, 12:09 PM.

                            Comment


                            • #44
                              Remember there are at least three unreleased episodes in the Star Wars arc. I expect Star Wars will outlive all of us.

                              Other than the 6xx/7xx 3D engine setup (in the pipe now, dev work going on in parallel) and some basic power management (5xx already happening, 6xx/7xx will follow 3D) what do you think is "totally incomplete" ?

                              We are going to look into the possibility of providing some video decode info (IDCT if not UVD) and are going to try to re-release some of the existing docs for older chips without NDA, but other than the above two areas I believe we have released everything I said we would.

                              Comment


                              • #45
                                Originally posted by bridgman View Post
                                Remember there are at least three unreleased episodes in the Star Wars arc. I expect Star Wars will outlive all of us.
                                Unfortunately George said he isn't doing the final 3 episodes.

                                Comment

                                Working...
                                X