Announcement

Collapse
No announcement yet.

Bettering Radeon Gallium3D Performance With PCI-E 2.0

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

  • #16
    But I imagine looking at e.g. the power saving code could still tell a very good programmer why radeon on the "low" profile still uses more power than fglrx.

    I mean, why doesn't AMD simply have somebody going over the code of catalyst, deleting everything patented or "secret" and release the nonfunctional rest? Could still be helpful for low level stuff like power saving and communicating properly with the hardware...

    Comment


    • #17
      Originally posted by ChrisXY View Post
      But I imagine looking at e.g. the power saving code could still tell a very good programmer why radeon on the "low" profile still uses more power than fglrx.

      I mean, why doesn't AMD simply have somebody going over the code of catalyst, deleting everything patented or "secret" and release the nonfunctional rest? Could still be helpful for low level stuff like power saving and communicating properly with the hardware...
      That's legal territory. Do not attempt to apply logic.

      Comment


      • #18
        Originally posted by ChrisXY View Post
        But I imagine looking at e.g. the power saving code could still tell a very good programmer why radeon on the "low" profile still uses more power than fglrx.

        I mean, why doesn't AMD simply have somebody going over the code of catalyst, deleting everything patented or "secret" and release the nonfunctional rest? Could still be helpful for low level stuff like power saving and communicating properly with the hardware...
        by the time thats get done mesa 12.1 would be the distro standard version, beside that code is useless for mesa is like asking microsoft to release their kernel code to improve linux powermanagement in laptops.

        mesa ppl already knows very clearly (prolly) what all the missing bits are and globally whats needed to face catalyst very close, what ppl seems to don't understand no matter how many times is explained is that mesa have like 5 DEVELOPERS and the code to handle GPU is EXTREMELY COMPLEX so is not like you can't magically shave out of your ass a couple of houndred thousand of lines code to magically make all work

        Comment


        • #19
          I just have the bad feeling that AMD will lose against intel in the GPU side too, on Linux.
          I wished they could focus on one thing but make it right.
          Missing features from r600g are 2D Tiling,HiZ, apparently PCI-E2, power saving. Why it is a problem for AMD employee to look at the catalyst, and see how these features are implemented(registers involved, state transitions, specific chips code-paths, etc), and re implement them on r600g? I am not talking here about *super secret* shader compiler(which nvidia may steal, and somehow adapt to their totally different architecture), but just enablement code.

          Comment


          • #20
            Originally posted by bug77 View Post
            That's legal territory. Do not attempt to apply logic.
            I don't mean copy-paste. I mean actual rewrite, but the code was already R&D.
            Apparently Intel are not afraid from legal issues.

            Comment


            • #21
              Originally posted by ChrisXY View Post
              But I imagine looking at e.g. the power saving code could still tell a very good programmer why radeon on the "low" profile still uses more power than fglrx.

              I mean, why doesn't AMD simply have somebody going over the code of catalyst, deleting everything patented or "secret" and release the nonfunctional rest? Could still be helpful for low level stuff like power saving and communicating properly with the hardware...
              The main problem is the sheer size of the Catalyst code relative to the size of the open source dev team. We tried sanitizing a much smaller code base (the "tcore" diagnostic platform) to kickstart r6xx support... spent ~9 months of part-time work on it and eventually gave up. The Catalyst power management code alone is bigger than the entire open driver stack.

              The challenge enabling things like tiling isn't "not knowing how to enable", it's that enabling tiling requires changes in a lot of different places and since the driver architectures are different you can't just look at the proprietary driver and find the corresponding areas in the open driver.

              Comment


              • #22
                Originally posted by jrch2k8 View Post
                mesa ppl already knows very clearly (prolly) what all the missing bits are and globally whats needed to face catalyst very close, what ppl seems to don't understand no matter how many times is explained is that mesa have like 5 DEVELOPERS and the code to handle GPU is EXTREMELY COMPLEX so is not like you can't magically shave out of your ass a couple of houndred thousand of lines code to magically make all work
                Yep, and we're actually talking about kernel driver code where the number of active open source developers is even smaller.
                Last edited by bridgman; 01-20-2012, 09:57 AM.

                Comment


                • #23
                  Originally posted by Drago View Post
                  Missing features from r600g are 2D Tiling,HiZ, apparently PCI-E2, power saving.
                  The first 3 just need kinks worked out before they become enabled by default, and power saving is present, but not as good as Catalyst at the moment. No reason for unnecessary panic..

                  Comment


                  • #24
                    Originally posted by DanL View Post
                    The first 3 just need kinks worked out before they become enabled by default, and power saving is present, but not as good as Catalyst at the moment. No reason for unnecessary panic..
                    Not panicking. Just I am concerned that Intel have way more weaker chips, but with stronger performance. They also have very good inertia so I expect event better performance/power numbers from them.

                    Comment


                    • #25
                      Originally posted by bridgman View Post
                      The main problem is the sheer size of the Catalyst code relative to the size of the open source dev team. We tried sanitizing a much smaller code base (the "tcore" diagnostic platform) to kickstart r6xx support... spent ~9 months of part-time work on it and eventually gave up. The Catalyst power management code alone is bigger than the entire open driver stack.
                      Oh dear, so I guess that suspend to ram etc. is so buggy (http://ati.cchtml.com/show_bug.cgi?id=153) because it is so complex that there inevitably are bugs all over the place?
                      Well, thanks for the answer.

                      Originally posted by bridgman View Post
                      The challenge enabling things like tiling isn't "not knowing how to enable", it's that enabling tiling requires changes in a lot of different places and since the driver architectures are different you can't just look at the proprietary driver and find the corresponding areas in the open driver.
                      I understand that and thus I was speaking about some low level functionality and that it could help, at least in some areas. Of course I assmue that there are some helpful comments on that code.

                      Comment


                      • #26
                        Michael, could you test this with the 2D tiling patch? I wonder how much these two combined would increase the performance.

                        Comment


                        • #27
                          Originally posted by bridgman View Post
                          The main problem is the sheer size of the Catalyst code relative to the size of the open source dev team. We tried sanitizing a much smaller code base (the "tcore" diagnostic platform) to kickstart r6xx support... spent ~9 months of part-time work on it and eventually gave up. The Catalyst power management code alone is bigger than the entire open driver stack.

                          The challenge enabling things like tiling isn't "not knowing how to enable", it's that enabling tiling requires changes in a lot of different places and since the driver architectures are different you can't just look at the proprietary driver and find the corresponding areas in the open driver.
                          Cool, thanks for the answer. I should have understood that since I'm a software developer myself. I prefer C++ over C though. So I guess the register stuff is the easy part and the framework/pipeline of it is the hard part?

                          Comment


                          • #28
                            Originally posted by Drago View Post
                            Just I am concerned that Intel have way more weaker chips, but with stronger performance.
                            Intel has 30+ developers while amd has 5, that's the difference.
                            ## VGA ##
                            AMD: X1950XTX, HD3870, HD5870
                            Intel: GMA45, HD3000 (Core i5 2500K)

                            Comment


                            • #29
                              Originally posted by darkbasic View Post
                              Intel has 30+ developers while amd has 5, that's the difference.
                              As much as I love AMD I still think that they are going to lose if things remain this way.

                              It appears though, that they understood recently that the good quality on the software side is essantial. What they still lack is the realisation that:
                              "If we pay 5 more guys we could conquer the _whole_ linux world."
                              This would mean roughly 2.5% increase in sales for them. I guess that means a higher revenue than the salary of those guys, i.e. profit.

                              Just my 2 cents though...

                              Comment


                              • #30
                                Now hold on, making a great mesa driver might make a difference for the technical users and those that care about their freedom, but there are hordes of Ubuntu users out there that just use Linux because it's free as in beer and couldn't care less what driver they use.

                                And don't get me wrong, I appreciate AMD's effort for making a free as in speech driver, and I'm using the radeon driver on my HD3650 from the days there was no 3D acceleration, not even the classical r600 driver. I just don't live the illusion that the majority of Linux users share my view regarding freedom.

                                Comment

                                Working...
                                X