Announcement

Collapse
No announcement yet.

Bringing The R600 Gallium3D Driver Up To Speed

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

  • #31
    Pretty well, really. We're running maybe 6 months behind my original expectations, mostly due to (a) the learning curve for classic mesa being longer than I expected, and (b) we ended up needing one more step in the rearchitecture effort than I had planned for. I was planning on just needing "old stack" and "new stack", but the realities of getting new code into the kernel meant that a third stack, the "radeon rewrite" effort, was required.

    The Evergreen changes were also more time-consuming than we planned -- the programming model changes were pretty much as expected but there was also a clean-up of the registers and bitfields, which was good for the hardware but bad for our plans to use a largely unchanged 6xx/7xx driver. There were also enough changes to the register specs that the nice simple IP review plan (diff the old and new register spec docs then review the relatively small diff) didn't work out so good in practice.

    Other than that, I guess things worked out more or less as expected - with the usual mix of good and bad along the way.

    Comment


    • #32
      Originally posted by bridgman View Post
      Richard is mostly working on things where the IP has not yet been reviewed/released, so his work tends to come out in large and infrequent chunks.
      OpenGL3OpenGL3OpenGL3OpenGL3OpenGL3OpenGL3OpenGL3
      OpenGL3 ! ;-) sorry i can't resist OpenGL3OpenGL3OpenGL3
      OpenGL3OpenGL3OpenGL3OpenGL3OpenGL3OpenGL3OpenGL3

      Comment


      • #33
        Originally posted by bridgman View Post
        Pretty well, really. We're running maybe 6 months behind my original expectations, mostly due to (a) the learning curve for classic mesa being longer than I expected, and (b) we ended up needing one more step in the rearchitecture effort than I had planned for. I was planning on just needing "old stack" and "new stack", but the realities of getting new code into the kernel meant that a third stack, the "radeon rewrite" effort, was required.

        The Evergreen changes were also more time-consuming than we planned -- the programming model changes were pretty much as expected but there was also a clean-up of the registers and bitfields, which was good for the hardware but bad for our plans to use a largely unchanged 6xx/7xx driver. There were also enough changes to the register specs that the nice simple IP review plan (diff the old and new register spec docs then review the relatively small diff) didn't work out so good in practice.

        Other than that, I guess things worked out more or less as expected - with the usual mix of good and bad along the way.
        I was referring more to the "not to write and release the drivers ourselves." .

        Comment


        • #34
          Originally posted by deanjo View Post
          I was referring more to the "not to write and release the drivers ourselves." .
          Yeah I guess they should do that since the open source community is falling down at developing most of the hard part of open source. The cries of "gives us the docs and we will do the work" seem to not be working out.

          Comment


          • #35
            Ahh, yes. That part

            In terms of perception, I don't think it's working at all. The development community understands, and we're all sending out a consistent message, but I don't think that message is being broadly understood. I guess part of the reason is that we have taken a different approach from the other hardware vendors, but I think that's OK since no two vendors were doing the same thing before

            The other problem is that right after we started the project the community launched into the whole KMS/GEM/TTM/DRI2/Galilum3D re-architecture effort, which sucked up almost all of the non-AMD community devs so we ended up focusing on implementing initial support for new generations of GPUs.

            Now that the rearchitecture work is largely finished we're starting to see the community developers building new features on top of the new architecture, so it's a lot easier than a year ago to see how much the community is contributing.

            Ask me again in a year

            Comment


            • #36
              I do *so* much miss the ability to edit. How did I end up with three smileys in one post ?

              Originally posted by kgonzales View Post
              Yeah I guess they should do that since the open source community is falling down at developing most of the hard part of open source. The cries of "gives us the docs and we will do the work" seem to not be working out.
              I believe things are working out the way the developers suggested, and our expectations were based on what the developers said.

              On the other hand, *outside* the development community I think most people underestimated the complexity of writing a modern graphics driver, and expected a complete, polished driver stack to appear in a matter of months. The reality is different, of course -- a full featured graphics driver stack is *millions* of lines of vendor-specific code, and even the current open soruce stack has perhaps 1/4 million lines of new or substantially modified code, plus perhaps a million lines of common code shared between HW vendors.

              Overall, I think it's worked out roughly the way we expected.

              Comment


              • #37
                Using my X1800 XT and latest gallium, (R520) I am still seeing screen corruption all over the place. Is this a documented bug?

                Comment


                • #38
                  Originally posted by kgonzales View Post
                  Yeah I guess they should do that since the open source community is falling down at developing most of the hard part of open source. The cries of "gives us the docs and we will do the work" seem to not be working out.
                  I'm not sure what documentation exactly you're talking about. AFAIK ATI/AMD has never released full documentation of their graphics cards, and for Evergreen they have released almost none. They have chosen themselves to release programming information in the form of header files and source code.

                  I'm sure a lot of people would actually prefer some quality documentation (e.g. same quality as Intel Architecture processor docs) for ATI graphics cards over the source and header files.

                  Comment


                  • #39
                    Originally posted by monraaf View Post
                    I'm not sure what documentation exactly you're talking about. AFAIK ATI/AMD has never released full documentation of their graphics cards, and for Evergreen they have released almost none. They have chosen themselves to release programming information in the form of header files and source code.

                    I'm sure a lot of people would actually prefer some quality documentation (e.g. same quality as Intel Architecture processor docs) for ATI graphics cards over the source and header files.
                    But would they get any great return on that investment in terms of driver writers? I suspect not. Most of the stuff that is released is suitable for building lots of higher level stuff like OpenCL etc, however I haven't see many people turn up and start writing compilers for GPUs or anything like that.

                    People always claim better docs will help but mostly I've found better docs just lead to better excuses.

                    Dave.

                    Comment


                    • #40
                      I hope the Gallivm3D r600 driver will really make the difference about performances. Today I switched to KMS(I have an ATI Radeon HD4850) with linux 2.6.33.3+(all the patches that are going to make release .4 that applied without failing), libdrm v2.4.20, mesa v7.8.1, xorg ati drivers v6.13.0. The performance of glxgears dropped from previous(UMS) 3207 to now(KMS) 2197!

                      Comment


                      • #41
                        Originally posted by bridgman View Post
                        Apart from ignoring Richard and Cooper's work (little things like the 6xx/7xx 3D driver), why is this something we should not be proud of ? On the closed source side we write the drivers; on the open source side tha plan was always to work with and support the developer community, not to write and release the drivers ourselves.

                        EDIT - Alex beat me again ;(
                        I don't want to hinder anybody's efforts. I was referring to the fact that so far you always said that you have 3 oss devs (which unfortunately decreased to 2 about half a year ago) and in addition only Alex's work is apparent to oss *consumers*. So I guess I was more like "you should not be proudly say we have 3 devs when it actually comes down to be just 1".

                        And some more about this "be proud" thing. Alex is doing an awesome work, granted. But still, evergreen is pretty much nowhere near, dynpm is far from being finished - I think this is AMD's side right now. On the oss side Jerome is writing r600g and Marek and Corbin *almost* finished r300g while Dave started so many projects to add some interesting features.
                        All in all, I had the feeling that AMD is falling behind on its part - in my opinion due to lack of manpower - and thus I said what I said. My intention was not to insult you or anyone, but it felt more like stating a fact that the oss side is currently doing a better job. Again, it's not your workers' fault but seems to be the lack of coders.

                        Providing the docs is much appreciated and seems to work just fine. I don't expect AMD to write all the drivers, but for example you should have done that with dynpm - just publish the powerplay bits of fglrx and don't make Alex and co. spend months to figure out how it works.

                        Please feel free to point out my mistakes and also to disagree.

                        Comment


                        • #42
                          Originally posted by HokTar View Post
                          [...]
                          Providing the docs is much appreciated and seems to work just fine. I don't expect AMD to write all the drivers, but for example you should have done that with dynpm - just publish the powerplay bits of fglrx and don't make Alex and co. spend months to figure out how it works.

                          Please feel free to point out my mistakes and also to disagree.
                          Code btw fglrx & opensource can't be shared, people shouldn't believe that cut & paste btw 2 different driver can work. AFAIK fglrx has a radical different design from radeon KMS. So all the infrastructure that dynamic power, or other features, need is too different to share code btw the 2 drivers.

                          In my experience, code reuse on big complex project is a myth.

                          And as John stressed out you don't write a full GL driver over a night no matter how good the doc you have are. Do you think someone with the intel doc on CPU can write a kernel over a night, a week, a month ? This kind of thing takes time (a GPU driver is as complex or maybe even more complex than a kernel, AFAIK fglx source code is bigger than linux kernel source).

                          Comment


                          • #43
                            It's a pitty to see that expectations about gallium being an unified driver with very common architecture, where vendors only need to implement a "small" winsys part for each chip model... apparently are not achieved, that small chip specific part appears to be, in fact, an huge chip specific part.

                            Comment


                            • #44
                              Originally posted by Jimbo View Post
                              It's a pitty to see that expectations about gallium being an unified driver with very common architecture, where vendors only need to implement a "small" winsys part for each chip model... apparently are not achieved, that small chip specific part appears to be, in fact, an huge chip specific part.
                              I hate to be a dickhead, but citation needed.

                              Nobody ever said gallium was going to be that.

                              The pipe driver has always been gpu specific, with the winsys being a GPU+OS specific interface.

                              Like large parts of how GPUs work can be common, but even larger parts are GPU specific. Its not like general purpose CPUs in that the GPUs generally take a lot of shortcuts for the sake of speed that a general purpose device could never take.

                              Dave.

                              Comment


                              • #45
                                Originally posted by MisterIO View Post
                                I hope the Gallivm3D r600 driver will really make the difference about performances. Today I switched to KMS(I have an ATI Radeon HD4850) with linux 2.6.33.3+(all the patches that are going to make release .4 that applied without failing), libdrm v2.4.20, mesa v7.8.1, xorg ati drivers v6.13.0. The performance of glxgears dropped from previous(UMS) 3207 to now(KMS) 2197!
                                glxgears is not a benchmark.

                                Comment

                                Working...
                                X