Announcement

Collapse
No announcement yet.

The State Of Open-Source Radeon Driver Features

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

  • #76
    Originally posted by Panix View Post
    Where did I make that comparison? I just contrasted how people act or more accurately, 'react' to what Nvidia and AMD/ATI do.

    AMD/ATI doesn't release all the specs as I understand it. There is no support with hardware acceleration and various licensing info or whatever restrictions there are. Also, on the feature set at the Radeon Feature web page, you can note all the 'features' that are listed as 'to do' yet that never changes. Nouveau developers have no help so yes, of course, that is a different situation. But, I didn't say that Nvidia and AMD/ATI are comparable regarding open source. I just said that AMD/ATI has overrated support - their support and investment in support is way lower than what many here try to assert. No one should be happy with these companies which bend over for Windows.
    I think it is a unique situation.

    In MS Windows people are in fact not allowed to write their own drivers, in fact you cannot load any unsigned driver since Windows Vista 64bit (I think). People could write their own driver, pay MS to sign it and then load it into the OS. There are some hacks to use a dodgy certificate etc. but I never passed the barrier to e.g. load a driver to a RAM drive or the ext2 drivers in recent versions.

    In Linux, people rather prefer to write their own drivers and AMD provides the information needed to do so. I am not following any discussions between the AMD people and Radeon developers and how much information is released. Often you hear bridgeman saying something like there could be improvements in the open driver compared to the binary. Then people ask to release the code of the binary driver, which is the big argument going on especially for power management.
    /{not sure part} The graphics card comes with power tables, which are set in the chip by the manufacturer like MSI, XFX etc. and those are accessable by the open driver. Many cheap cards lack enough steps in those tables... it seems the binary driver can work around this problem and scale the frequencies independently {not so sure part}/

    Additionally there is still the firmware, which needs to be loaded into the kernel and is provided by AMD (the firmware for the Nouveau drivers are kind of legally provided, because people would need to download the driver from Nvidia and extract the part themselves to be legal). This is how much AMD does so far and I think it is a lot.
    Last edited by disi; 09-05-2012, 11:41 AM.

    Comment


    • #77
      Originally posted by jrch2k8 View Post
      not sure is 5 is the right numbers but as far as i know this fill the entry i writed before -- provide skeleton code/support and ofc they can contribute to other parts of the code that they see fit since is an OSS project but i think bridgman can provide a more precise answer of their jobs exactly

      the fact AMD pay some devs to improve things is not different than MyXcompany. inc doing it or yourXcompany. inc doing it since the code they provide follow the project guidelines and is not managed or owned by AMD

      ofc AMD maybe interested in help to bring faster certain features to r600g for internal reasons but it doesnt make their driver or property they are just another contributor
      http://en.wikipedia.org/wiki/Graphic...FOSS#ATI.2FAMD

      Comment


      • #78
        Everything is cited with Michael Larabel I guess its true but just because its written on wikipedia...

        Comment


        • #79
          Originally posted by Henri View Post
          Yeah well, lots of people read something on a forum somewhere and then repeat it. Unfortunately none of them actually know what they're talking about, and it's complete BS.
          Yea, from what reliable information I have seen, NVIDIA hardware is better supported just because FGLRX was heavily bug-ridden for a long time.

          Comment


          • #80
            Originally posted by GreatEmerald View Post
            Yea, from what reliable information I have seen, NVIDIA hardware is better supported just because FGLRX was heavily bug-ridden for a long time.

            Example of Nvidia quality: It was 2010-2011 when Nvidia gave static-compiling support for Linux. When the GLSL-compiler compiles and optimizes graphics(shaders), Nvidia driver saves this code (probably in home folder, MBytes to GBytes). Then with some hacks, the driver doesn't compile again the same thing. So the game is slower only the first time you run it.

            Comment


            • #81
              Originally posted by bridgman View Post
              You might be thinking that I'm thinking about a higher level of support than... um... than you think. (that didn't come out right)



              Yes, although AFAICS the biggest pain point for users is not lack of slick dynamic PM but not even having enough entries in the tables to use the current profile mechanism fully. First priority would seem to be interpolating between the low and high settings in the current tables.
              Hmm most the feedback I see if for dynamic PM not better static PM, static PM is crap, no use in laptops at all, we also want to be able to use the Fusion GPUs up to their package limits, like we can't upclock the APU because it'll overheat, so even if the BIOS has the table we can't use it because we have no decent thermal protection. We should be able to use AMD APU like we use Intel CPUs and we can't. There are so many problems we just can't solve and the ones we can solve there is little demand from people I talk to.

              static profiles might work for people on phoronix, but they don't save power for the 99% of people who install RHEL and never read the online docs (i.e. my customers).

              Dave.

              Comment


              • #82
                I don't think there's any disagreement on where we need to get to... the only question is whether it's worth doing anything in the interim.

                Static PM is just a first step, but the most unhappy users I see are the ones who can't even get that working with help. I agree static PM is a non-starter for server customers and that is one of the points we're using to drive discussions internally; not sure I completely agree about laptops though.

                Comment


                • #83
                  Originally posted by bridgman View Post
                  I don't think there's any disagreement on where we need to get to... the only question is whether it's worth doing anything in the interim.

                  Static PM is just a first step, but the most unhappy users I see are the ones who can't even get that working with help. I agree static PM is a non-starter for server customers and that is one of the points we're using to drive discussions internally; not sure I completely agree about laptops though.
                  If the users make it this far to ask then they are in the possibly 5% of users who care, I can't provide a proper OS on top of that, its crap.

                  In servers we care a bit, but on laptops they need to the right thing without specific configuration, the shit we did 5 years ago doesn't cut it any more, and its not like this stuff is getting simpler, so doing the dumb thing for evermore is just pointless. By the time we get to doing smart stuff for any of the current GPUs they'll find another reason for blocking doing smart stuff for newer chips. This requires someone in AMD with some power to overrule the idiocy that is blocking PM code. You guys own the hardware, you guys are diong the same things as nvidia and intel, if you have some innvoation in r600-trinity that nobody knows about at this stage I'd be shocked and amazed that anyone gives a shit. Just release the code already, and arrange for anyone who tries to block it to find a new position where being an idiot is acceptable.

                  Dave.

                  Comment


                  • #84
                    Ahh, I think I see the disconnect. You're talking about this as an either-or, where working on current PM code is an alternative to (or, worse, could delay) the release of more information.

                    I'm just saying "that work is proceeding, but maybe not as fast as we would like, what do we do in the meantime ?".
                    Last edited by bridgman; 09-06-2012, 05:19 AM.

                    Comment


                    • #85
                      Originally posted by bridgman View Post
                      I'm just saying "that work is proceeding, but maybe not as fast as we would like, what do we do in the meantime ?".

                      Pray for some pissed hacker to reverse engineer the thing and release the code.

                      Comment


                      • #86
                        Originally posted by bridgman View Post
                        Ahh, I think I see the disconnect. You're talking about this as an either-or, where working on current PM code is an alternative to (or, worse, could delay) the release of more information.

                        I'm just saying "that work is proceeding, but maybe not as fast as we would like, what do we do in the meantime ?".
                        Well if someone rips up the current code and makes it a lot better, the work you've done will require another rewrite and then let me guess another review, which someone else will find another reason to block. The best chance is for the current code to not move so we can avoid any future AMD review process :-)

                        But really AMD spent a lot of money on hw designers to make the chips do this stuff, actively working against the hw designers design seems both pointless and stupid, especially when the same company is paying people to waste their time.

                        Dave.

                        Comment


                        • #87
                          Well maybe amd has to update the legacy driver branch(es) to support newer xservers until the oss driver has pm, that would be a logical consequence - but most likely amd want to be responsible for lots of overheating laptops running Linux.

                          Comment


                          • #88
                            Originally posted by airlied View Post
                            Well if someone rips up the current code and makes it a lot better, the work you've done will require another rewrite and then let me guess another review, which someone else will find another reason to block. The best chance is for the current code to not move so we can avoid any future AMD review process :-)

                            But really AMD spent a lot of money on hw designers to make the chips do this stuff, actively working against the hw designers design seems both pointless and stupid, especially when the same company is paying people to waste their time.

                            Dave.
                            i kinda remember[ish] that nouveau had a set of tools to intercept every call made to the GPU and i think it somehow extracted pm data too[i remember sending dumps of my old but thrustworthy 8800gts], so maybe this tool could be modified to do the same thing with FGLRX and keep that code out of tree along with a place to keep the dumps??

                            Comment


                            • #89
                              Originally posted by bridgman View Post
                              Is it worth trying to match fglrx with the current code ? I don't think so (other than for r600 and below). Is it worth improving the current code enough to give a bunch of current users full use of the profile mechanism (and maybe a few options in between), particularly on middling-old hardwere ? I think so...
                              Having written a bunch of the existing Radeon PM code, I've no doubt that it could be better. But the incentive to make it better when we know that we *can't* make it as anywhere near as useful as fglrx is limited. Any kind of worthwhile power management on Radeon is going to involve running code on the chip itself, and that's not something you've documented. So yeah, I could spend a few months on getting us reliably reclocking during vblank, but it'd still be something that almost everyone would turn off because it'd have an awful performance impact. There's just not a great deal of incentive, especially since AMD have already written code to do it and are choosing not to release it.

                              Comment


                              • #90
                                Originally posted by mjg59 View Post
                                Having written a bunch of the existing Radeon PM code, I've no doubt that it could be better. But the incentive to make it better when we know that we *can't* make it as anywhere near as useful as fglrx is limited. Any kind of worthwhile power management on Radeon is going to involve running code on the chip itself, and that's not something you've documented. So yeah, I could spend a few months on getting us reliably reclocking during vblank, but it'd still be something that almost everyone would turn off because it'd have an awful performance impact. There's just not a great deal of incentive, especially since AMD have already written code to do it and are choosing not to release it.
                                Hi Matthew;

                                I had the same discussion with Dave a page or two back. I'm not even suggesting going that far at this point.

                                I don't understand your comment about "already written code". I'm sure you understand that for new hardware writing code is just the first step of what can be a very long process with a lot of rewrites and may never result in a release. It's possible that the info you received under NDA was incomplete and suggested that the code was going to be released very soon, if so please let me know privately and I'll try to fix that.

                                Comment

                                Working...
                                X