Announcement

Collapse
No announcement yet.

ATI R300 Mesa, Gallium3D Compared To Catalyst

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

  • #46
    Originally posted by krazy View Post
    stupid, unfunny and wrong to boot. fail.
    Whatever...

    Comment


    • #47
      It's a fact that many people refuse to publish code under the BSD license, especially after companies like Microsoft hijacked code and closed it and put it into their expensive solutions.

      Svartalf was pointing at that. That's the cause. The rate of development of Linux can be explained at least in part through this documented fact. I guarantee you that SGI would not have released XFS under the BSD license, and that Sun would not have released StarOffice or Java (!!!! lol) under the BSDL.

      He doesn't need to suggest that people don't like the BSDL, as a programmer with many years of experience in the Linux/BSD world, he is perfectly aware that there are many people who use the (L)GPL for these reasons.

      To be honest, the situation is probably quite different for GPU drivers, which are so specialised and tied to so many other things, that ripping the code (to create a closed driver) would be pretty useless anyway.

      Comment


      • #48
        I am a user of ATI X1300 (no longer supported by the linux propietary driver anymore). I don't stop updating the kernel because of the GPU. The propietary driver stopped compiling about a year ago. For me the performance difference of r300g versus fglrx is huge: r300g works, fglrx doesn't work.

        Thanks for your work guys. I'd love to help, but not being a developper is a big stopper.

        Comment


        • #49
          I realy like to contribute code somewhere in/to the driver stack. I realy dislike doing so in non-gpl but then again this is not a solo show and thus arguing about the more liberal license is just... totaly stupid/futile/egocentric/etcetera.

          Comment


          • #50
            It's hard to tell whether relicensing the graphics stack to GPL would attract more developers. There's always talk from people saying that they want to contribute to the graphics drivers. But saying you want to and actually contributing are two different things.

            On the other hand, the more liberal license of the graphics stack has not yielded in any significant contributions from the BSD camp. And they've been leeching on Linux code for quite some time now.

            Personally I would be in favor of relicensing to LGPL. But that's something for the actual contributors to decide.

            Comment


            • #51
              The switch from wanting to contributing doesn't happen overnight... Hello World != coding a GPU driver you know...

              Comment


              • #52
                Well, the GPU drivers are obviously suffering from the lack of community contributions. Of course, there is significant work being done by a number of community developers, but I don't think that it's realistic to expect the GPU drivers to be written 95% by the community, like many large FLOSS projects are.

                I think that Gallium3d is a step in the right direction. It centralises lots of the technology, so it is much more reusable. It should make writing drivers easier. But I'm guessing that we'll still be dependent on the manufacturers for much of the basic infrastructure work for new GPUs.

                The reason why open drivers lack behind the closed ones is that writing GPU drivers is not easy, and takes lots of manpower.

                Comment


                • #53
                  Originally posted by monraaf View Post
                  It's hard to tell whether relicensing the graphics stack to GPL would attract more developers.[...]

                  On the other hand, the more liberal license of the graphics stack has not yielded in any significant contributions from the BSD camp.[...]
                  It's not about developers, but about users (that's you). There's a reason why the licenses are either MIT or LGPL. Programs (thus users) have to use those libraries, regardless of what license those programs are written on. Or else you won't play much Q3 with the OSS drivers.

                  Comment


                  • #54
                    Originally posted by V!NCENT View Post
                    I realy like to contribute code somewhere in/to the driver stack. I realy dislike doing so in non-gpl but then again this is not a solo show and thus arguing about the more liberal license is just... totaly stupid/futile/egocentric/etcetera.
                    Heh... You'll note there was this 3D stack for Linux that precedes the current DRM framework, called Utah-GLX. It was licensed under the MIT/X11 license. I was one of their contributors/maintainers for a long while.

                    Did I mention I prefer LGPL and usually release stuff under it and the GPL?

                    Your reasoning is why I did what I did and would do it again, in light of things.

                    Comment


                    • #55
                      Originally posted by V!NCENT View Post
                      The switch from wanting to contributing doesn't happen overnight... Hello World != coding a GPU driver you know...
                      Definitely not. It's a brutally hard thing, requiring roughly the same level of ability as keeping up with the key people in lkml. There is a reason why it's slow. There is a reason why the Linux AMD proprietary driver has been very dodgy in the past.

                      Comment


                      • #56
                        Originally posted by yotambien View Post
                        It's not about developers, but about users (that's you). There's a reason why the licenses are either MIT or LGPL. Programs (thus users) have to use those libraries, regardless of what license those programs are written on. Or else you won't play much Q3 with the OSS drivers.
                        Actually, if it's LGPLed only, it'd not impact the users at all.

                        It really is more about the pool of available people willing to do the work and have the right skills to do it. It's not an easy thing doing this stuff- and at least until Gallium's done, you're going to need a developer at least a couple of cuts above average to do the work.

                        Comment


                        • #57
                          Originally posted by pingufunkybeat View Post
                          Well, the GPU drivers are obviously suffering from the lack of community contributions. Of course, there is significant work being done by a number of community developers, but I don't think that it's realistic to expect the GPU drivers to be written 95% by the community, like many large FLOSS projects are.
                          One could say the same thing about the OS itself.

                          I think that Gallium3d is a step in the right direction. It centralises lots of the technology, so it is much more reusable. It should make writing drivers easier. But I'm guessing that we'll still be dependent on the manufacturers for much of the basic infrastructure work for new GPUs.
                          The basic infrastructure's amazingly similar in nature for most GPUs.

                          It's going to be more in knowing where the vicious pinch-points are within the architecture of a given chip- and then avoiding them when you're feeding command streams to it. We're going to probably start seeing incremental boosts in performance with the FOSS Radeon support here in a little bit as the final pieces of Gallium seem to be gelling. This would be them removing things that bottleneck the GPU or the CPU at the worst possible times. All it takes is a 1msec stall in the pipelines to drag you to the floor in framerates on things.

                          You might need the vendor's help on that part, you might not.

                          The reason why open drivers lack behind the closed ones is that writing GPU drivers is not easy, and takes lots of manpower.
                          I would hesitate to say "lots" of manpower, but it certainly takes more highly skilled people than are available right now- whether you're talking about AMD's fglrx or the FOSS Gallium stuff.

                          Comment


                          • #58
                            If I'm not mistaken, both the FGLRX and the Nvidia driver teams number quite a few full-time developers.

                            I don't know if it qualifies as "lots of manpower", but it's probably far more than the number of people working on FLOSS drivers full time. And they have 15 years of accumulated optimisations and a large head start on top of that.

                            Comment


                            • #59
                              Originally posted by pingufunkybeat View Post
                              If I'm not mistaken, both the FGLRX and the Nvidia driver teams number quite a few full-time developers.
                              There's less on the AMD side than the NVidia side right at the moment, but the point's taken.

                              I don't know if it qualifies as "lots of manpower", but it's probably far more than the number of people working on FLOSS drivers full time. And they have 15 years of accumulated optimisations and a large head start on top of that.
                              No, it really doesn't qualify as a "lot of manpower" on the side of the equation we're talking about- but the cumulative years of experience on what to/not to do with this stuff does offset that some. Once you hit a certain threshold, though, they become a bit more obvious and clear with observation of what's going on when you do <X> within the driver. It took me about 6 months to start beginning to get "useful" with my client's Windows side sustaining engineering work (Doing OpenGL drivers, mind...)- at which point the contract was up and they didn't have budget to continue with me and one other contractor working for them. This was picking up the knowledge that we're discussing here and then trying to make use of it to fix busted applications.

                              The same will be probably true for the Gallium driver framework once the whole thing gels and they start doing the other part of that learning curve. It'll take a bit longer than I took to get up to speed with things on my contract, mainly because they won't have full access to the knowlege base I had (One of the OpenGL ARB reps and a co-author of one of the best books on OpenGL was my boss while I was working there...) but it will come and you will start getting a few more people interested once they see it's repeatable (right now it's a lot harder work than it needs to be because you're duplicating things within each of the drivers available- which makes it difficult to optimize anything or fix a range of issues in the driverspace...).

                              Comment


                              • #60
                                Don't confuse yourself with the blobs. We are talking about a shitload of "must work now!", complexity due to legacy and then changing and achanging the codebase, undecrypted processing all acros the board, coding while not even finnished [gpu], sorting out errors, zero creativity due to zero legal limitations, not something they believe in (proprietary), deadlines, win/mac/linux environment with different interfaces and meetings, etc, etc, etc...

                                Comment

                                Working...
                                X