Announcement

Collapse
No announcement yet.

The State Of Open-Source Radeon Driver Features

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

  • #91
    Originally posted by bridgman View Post
    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.
    Maybe I'm misunderstanding your chip architecture, but my impression was that it was similar to nvidia - ie, a separate microcontroller that executed code to perform the power management operations. The code to drive that microcontroller clearly already exists, since fglrx uses it. For us to drive it would require us to reverse engineer the microarchitecture, write a toolchain and figure out how to integrate it into the driver. You're in a position to shortcut several of those steps.

    Like I said, we could improve the existing static power management, but no matter how much effort we put into it it still wouldn't be good - I'd be amazed if it could even approach a level that you could plausibly describe as "adequate". There's just no motivation whatsoever to spend that much time in order to provide something of marginal benefit to users when the same amount of time would provide much larger benefits elsewhere.

    Comment


    • #92
      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...
      So where would a new developer start working on that? I read half the morning through X.org-wikis and other stuff and still have absolutely no clue where to start looking for more info/guidance. Or I need a break because of information overflow

      Comment


      • #93
        Originally posted by bridgman View Post
        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.
        I just have to answer on this: absolutely not. I do care about PM, but I don't care about static PM at all. If it's not dynamic and hassle-free, I'm not going to touch it. And I really can't understand how anyone could come to the conclusion to put any effort into static PM ... since I strongly believe that 99.9% of even the tech-savy linux users won't ever know about or use static PM. Things like that need to just work.

        I can't help doing some more ranting: I'm beginning to doubt AMD's linux strategy in recent months - I've been faithful for a long time (since before I bought my 4870's) and had a lot of patience. But with the 4xxx generation apparently getting out-of-focus of development while still missing lots of features (like PM) and not gaining a lot of performance improvements anymore, it seems highly doubtful to me that cards from that generation will ever be generally usable with the open-source drivers. With generally usable I mean the often mentioned "within 10% of fglrx performance". I'd be happily satisfied with perormance at 70% of fglrx. Unfortunately it's nowhere near that in my experience - and I don't believe it'll get there anymore in the next 2-3 years while those cards will be still ok to use for gaming.

        The problem is that while AMD releases docs and employs some developers, it doesn't seem to me that that their driver is much more advanced than nouveau. I can use r600g for X and some light 3D (say Quake Live) well enough, but I can do the same on nouveau on my GeForce 8600M. But I cannot use fglrx - since it never supports the most recent X server fast enough (I'm on gentoo). With the nvidia-blob, support arrives much faster and I probably could wait a week or two with updating X for the driver to support it.

        So with nouveau I get a basic reverse engineered driver without any firmware-tainting like AtomBIOS that is fully open and a binary blob I can use when I absolutely need performance.
        With r600g I get the same basic driver but with firmware-tainting through AtomBIOS, but I can't use fglrx since it's so damn slow to support new X versions. Well, fglrx isn't an option anymore anyway, since support for my cards got dropped.

        And then there is the issue with radeonsi - still no usable support afaik - so it doesn't seem like it'll get any better with future generations. Although there are statements that HD8000 will be the first generation to see launch-day 3D support. I simply cannot believe that considering the awful state radeonsi is in.

        I'd really like to support AMD, since I believe competition (against the big ones, nvidia and intel) is important, and I think that there are a lot of good ideas within AMD (like opening up docs or supporting coreboot), but at the moment I'd just buy lower performing and worse supported hardware. I believe AMD could really gain a lot if they really embraced the idea of opening up their stuff.
        Last edited by mazumoto; 09-09-2012, 04:42 PM.

        Comment


        • #94
          Originally posted by mazumoto View Post
          I just have to answer on this: absolutely not. I do care about PM, but I don't care about static PM at all. If it's not dynamic and hassle-free, I'm not going to touch it. And I really can't understand how anyone could come to the conclusion to put any effort into static PM ... since I strongly believe that 99.9% of even the tech-savy linux users won't ever know about or use static PM. Things like that need to just work.

          I can't help doing some more ranting: I'm beginning to doubt AMD's linux strategy in recent months - I've been faithful for a long time (since before I bought my 4870's) and had a lot of patience. But with the 4xxx generation apparently getting out-of-focus of development while still missing lots of features (like PM) and not gaining a lot of performance improvements anymore, it seems highly doubtful to me that cards from that generation will ever be generally usable with the open-source drivers. With generally usable I mean the often mentioned "within 10% of fglrx performance". I'd be happily satisfied with perormance at 70% of fglrx. Unfortunately it's nowhere near that in my experience - and I don't believe it'll get there anymore in the next 2-3 years while those cards will be still ok to use for gaming.

          The problem is that while AMD releases docs and employs some developers, it doesn't seem to me that that their driver is much more advanced than nouveau. I can use r600g for X and some light 3D (say Quake Live) well enough, but I can do the same on nouveau on my GeForce 8600M. But I cannot use fglrx - since it never supports the most recent X server fast enough (I'm on gentoo). With the nvidia-blob, support arrives much faster and I probably could wait a week or two with updating X for the driver to support it.

          So with nouveau I get a basic reverse engineered driver without any firmware-tainting like AtomBIOS that is fully open and a binary blob I can use when I absolutely need performance.
          With r600g I get the same basic driver but with firmware-tainting through AtomBIOS, but I can't use fglrx since it's so damn slow to support new X versions. Well, fglrx isn't an option anymore anyway, since support for my cards got dropped.

          And then there is the issue with radeonsi - still no usable support afaik - so it doesn't seem like it'll get any better with future generations. Although there are statements that HD8000 will be the first generation to see launch-day 3D support. I simply cannot believe that considering the awful state radeonsi is in.

          I'd really like to support AMD, since I believe competition (against the big ones, nvidia and intel) is important, and I think that there are a lot of good ideas within AMD (like opening up docs or supporting coreboot), but at the moment I'd just buy lower performing and worse supported hardware. I believe AMD could really gain a lot if they really embraced the idea of opening up their stuff.
          God I hate when people like you think they are informed, atombios isn't firmware tainting, stop talking bullshit until you actually understand things,.yes you are probably right be disappointed, but you should probably learn what you are disappointed about or just state you are ignorant up front.

          Dave.

          Comment


          • #95
            Originally posted by airlied View Post
            God I hate when people like you think they are informed, atombios isn't firmware tainting, stop talking bullshit until you actually understand things,.yes you are probably right be disappointed, but you should probably learn what you are disappointed about or just state you are ignorant up front.
            Aww, sorry, I guess I mixed up things there then. I thought the firmware that I need to install is for talking to AtomBIOS more or less. I probably got to that conclusion because of that long past argument between radeonhd and radeon developers - I've been under the impression that the radeonhd-folks didn't want any black-box-blobs in the driver whereas the radeon driver which leverages AtomBIOS needs such blobs. But I didn't follow the whole thing very thoroughly, so I might be wrong there too.
            Yet I can't help it to like what the nouveau guys did with their "FUC" blobs - writing an open implementation for them. That basically was what I wanted to express by using the word "firmware-tainting".

            Actually I'm not sure disappointed is the right word here - I was well aware that the open drivers might never get anywhere near as good as suggested back when I bought my cards. I'd rather call it frustrating to see that while AMD has (in my opinion) the better philosophy of opening things up, it doesn't really come to fruitition - in some aspects it even seems worse by being bound to NDAs and maybe even less community interest (because everybody just waits for AMD to deliver whereas with NVIDIA it's crystal clear that it must be done by the community).
            Hence it's not a personal thing of disappointment, but rather a hypothesis that while NVIDIA doesn't have an open strategy, their model might be no worse for open source than AMD's while customers seem to gain by their way of doing things. (Which I want to repeat is quite sad).

            Basically I wanted to nudge bridgman with that, not you ;-)

            Comment


            • #96
              Originally posted by airlied View Post
              God I hate when people like you think they are informed, atombios isn't firmware tainting, stop talking bullshit until you actually understand things,.yes you are probably right be disappointed, but you should probably learn what you are disappointed about or just state you are ignorant up front.

              Dave.
              Uncalled for. Apart from that he's pretty much spot on.

              Comment


              • #97
                Originally posted by mazumoto View Post
                ...... I'd rather call it frustrating to see that while AMD has (in my opinion) the better philosophy of opening things up, it doesn't really come to fruitition - in some aspects it even seems worse by being bound to NDAs and maybe even less community interest (because everybody just waits for AMD to deliver whereas with NVIDIA it's crystal clear that it must be done by the community).....
                Opensource AMD Graphics Driver is a pipe dream!
                Remember when AMD Fusion Series released, when the opensource driver for it was tauted about? Yes, it's been more than two years. The development has almost been static. Funny enough but true - opensource graphics driver for AMD E350 is much slower than the graphics that came with Pinetrail Atom chips. Meaning, it makes no sense to use those graphics drivers.

                What's more the fglrx driver integration into linux is not that smooth either. It's buggy and complicated compared to propriatary nvidia graphics.

                #1 Use either Intel or Nvidia graphics if you're looking for satisfactory performance on linux
                #2 or Turn to Windows and use catalyst - it's great, very economical and feature complete

                Comment


                • #98
                  I beg to differ. The 3150 - a repackaged 945 - is not faster than the E-350/450, both running open source drivers.

                  Source: own both.

                  Comment


                  • #99
                    Originally posted by curaga View Post
                    I beg to differ. The 3150 - a repackaged 945 - is not faster than the E-350/450, both running open source drivers.

                    Source: own both.
                    I totally agree, even my AMD C-50 netbook is faster than the Intel Atom gpu
                    http://openbenchmarking.org/result/1...GR-1110220LI26

                    And those tests are quiet old, there has been a lot of improvement for the radeon driver in the meantime...

                    //edit: and with a proper dedicated card, I can compete with the catalyst driver on a new A-10 chip (at least with Urban Terror):
                    http://openbenchmarking.org/result/1...BY-1208141BY14
                    Last edited by disi; 11-22-2012, 04:49 AM.

                    Comment


                    • Originally posted by manmath View Post
                      Opensource AMD Graphics Driver is a pipe dream!
                      Remember when AMD Fusion Series released, when the opensource driver for it was tauted about? Yes, it's been more than two years. The development has almost been static. Funny enough but true - opensource graphics driver for AMD E350 is much slower than the graphics that came with Pinetrail Atom chips. Meaning, it makes no sense to use those graphics drivers.

                      What's more the fglrx driver integration into linux is not that smooth either. It's buggy and complicated compared to propriatary nvidia graphics.

                      #1 Use either Intel or Nvidia graphics if you're looking for satisfactory performance on linux
                      #2 or Turn to Windows and use catalyst - it's great, very economical and feature complete
                      The only thing that might be better with an Atom is video playback (E-350 with r600g certainly does not have hardware acceleration, not sure about Atoms). If an Atom is faster at anything else then E-350 + r600g you either have a defective unit or your software stack is messed up. Try a liveusb with the latest release of Fedora for example to see if it's a software problem.

                      Comment


                      • Originally posted by Ansla View Post
                        The only thing that might be better with an Atom is video playback (E-350 with r600g certainly does not have hardware acceleration, not sure about Atoms).
                        They don't. Even the newer desktop chipset, GM45, still doesn't have it properly working.

                        (I don't know whether the blobs for the PowerVR atoms support any. But who wants to inflict those on themselves?)

                        Comment


                        • Originally posted by curaga View Post
                          I beg to differ. The 3150 - a repackaged 945 - is not faster than the E-350/450, both running open source drivers.
                          Well, I've not benchmarked. But from pure perception (i've both and well configured) E-350 on opensource driver is unable to play HD video smoothly, if at all. Same is true for intel 3150. Whereas on pure graphics hardware muscle everyone is aware that e-350 is better. Now the point is what's the value of running E-350 on opensource driver and getting somewhat the same (or just little more) performance as an atom??? And what's the use of "OpenSource Driver" if it's feature incomplete and offers only 25% performance of the proprietary drivers? Besides, if anyboy have tracked the development of opensource radeon drivers, it's quite clear that it's been one of the MOST slowest developing project...
                          Last edited by manmath; 11-22-2012, 06:16 AM. Reason: typo

                          Comment


                          • What's the use of running an Atom and getting "only slightly" less performance then the E-350? The E-350 is cheaper, uses a similar amout of power and has better performance even with the incomplete mesa drivers. So I'm happy with my E-450 based laptop, it's a huge improvement from the crappy Atom based one I had before.

                            Comment


                            • Originally posted by manmath View Post
                              Well, I've not benchmarked. But from pure perception (i've both and well configured) E-350 on opensource driver is unable to play HD video smoothly, if at all. Same is true for intel 3150. Whereas on pure graphics hardware muscle everyone is aware that e-350 is better. Now the point is what's the value of running E-350 on opensource driver and getting somewhat the same (or just little more) performance as an atom??? And what's the use of "OpenSource Driver" if it's feature incomplete and offers only 25% performance of the proprietary drivers? Besides, if anyboy have tracked the development of opensource radeon drivers, it's quite clear that it's been one of the MOST slowest developing project...
                              This, all the statements of Atom being faster are not true and the AMD chip is cheaper.

                              On Linux the open drivers are much better integrated into the system e.g. work natively with new xorg-releases, xrandr etc. Nobody has to wait for AMD or NVIDIA to update their drivers for new features or bug-fixes.

                              Comment


                              • Originally posted by manmath View Post
                                E-350 on opensource driver is unable to play HD video smoothly, if at all. Same is true for intel 3150.
                                This has 100% nothing to do with graphics. The open source radeon driver only has hardware decode for mpeg2 (and I doubt your HD video was mpeg2). The intel 3150 doesn't have any video decode unit.

                                People do this a lot, talk about "GPU video playback" in scenarios where the video is decoded entirely in software.


                                Originally posted by curaga View Post
                                I don't know whether the blobs for the PowerVR atoms support any. But who wants to inflict those on themselves?
                                I believe EMGD (poulsbo driver) has VAAPI, don't know about cdv (cedarview driver). Though you're 100% correct about the inflicting part. ValleyView can't get here soon enough.

                                Comment

                                Working...
                                X