Announcement

Collapse
No announcement yet.

AMD, please give us EGL or decent direct rendering.

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

  • #46
    Originally posted by zappa86 View Post
    I find the discussion of which company (AMD or Nvidia) supports linux better and how they do it as interesting as the next person, but lets stay on topic here. Were discussing the fglrx and what needs to be done to improve it.
    I second that. Somehow the topic got completely lost.

    Anyway, bridgman knows what's wrong now but i would like to know what's gonna happen now on the AMD side of this issue?
    bridgman, feel free to respond

    Comment


    • #47
      Originally posted by Panix View Post
      The FOSS driver is not 100% optimized as has been explained and discussed over and over. Performance wise, I try to recall the figure but for e.g., 70% of the binary performance. For some, that is enough but not necessarily everyone.

      I think if you are lacking features and performance, then one can be justified at considering options that allow for full performance and features.

      The same features continue to be absent in the open source driver (look at the radeon feature matrix) and the performance is not fully optimized so obviously, it's not 100% open and the resources invested are lacking. It is just a matter of opinion whether you accept this caveat and can live with it.

      Even though the proprietary driver is vilified here, if one buys a brand new card, they expect full features and performance, whatever the card can do. Unfortunately, the benchmark or comparative scale is via the latest Windows OS. But, these hardware companies are catering their editions to MS and the MS OS. Unless the open drivers are open to the point in which there is full openness to go from, there is always restrictions. So, it's based on tradeoffs?

      Also, buying the AMD card, one is expected to bug track and troubleshoot if you want to contribute to the expanding improvement? It's a good idea but I am curious what time and expertise is needed... there is not as much investment from the company itself so you are expected to do a significant share.

      Also, the improvement or progress of the FOSS driver is not motivated by money as much as the proprietary so there is a positive and negative benefit to that.
      If they buy a video card and expect "full performance" then they should be using Windows, full stop. The only reason to want "full performance" from a graphics card (not compute card) is to play games and those just aren't nearly as well supported on Linux, full stop.
      If you are using Linux then you shouldn't expect "full performance" from your gfx card. Stop whining. The situation is so much better now with open drivers than it ever was, and it is always improving. Have patience or use Windows (i.e., the only system that provides "full performance" with said gfx card).

      Thanks airlied for the hard work, and bridgman for the patience.

      Comment


      • #48
        Originally posted by markg85 View Post
        Anyway, bridgman knows what's wrong now but i would like to know what's gonna happen now on the AMD side of this issue? bridgman, feel free to respond
        No idea. I'm going to ask around to see if our folks agree with the GL 1.1 limit with indirect rendering and what our current understanding is re: running compositors or otherwise making heavy use of TFP via direct rendering. The trick then will be seeing if the issues can be considered a problem on any of the environments, applications or distros we actively support.

        I guess I'll poke around in the bug tracker to see if there is a relevant ticket filed as well, if I feel up to wading through the insults and death threats.

        Comment


        • #49
          Originally posted by bridgman View Post
          No idea. I'm going to ask around to see if our folks agree with the GL 1.1 limit with indirect rendering and what our current understanding is re: running compositors or otherwise making heavy use of TFP via direct rendering. The trick then will be seeing if the issues can be considered a problem on any of the environments, applications or distros we actively support.

          I guess I'll poke around in the bug tracker to see if there is a relevant ticket filed as well, if I feel up to wading through the insults and death threats.
          Which bug tracker? The amd one? Or the one that was linked to somewhere in this thread?

          And could you please keep us up to date on the progress? I'm asking because I really want to use either opengl 2 or es in kwin simply because that is supposedly giving better performance on kwin..

          Regards,
          Mark

          Comment


          • #50
            Originally posted by bridgman View Post
            No idea. I'm going to ask around to see if our folks agree with the GL 1.1 limit with indirect rendering and what our current understanding is re: running compositors or otherwise making heavy use of TFP via direct rendering. The trick then will be seeing if the issues can be considered a problem on any of the environments, applications or distros we actively support.
            Well, sooner or later Red Hat will start using Gnome Shell. So I guess it just depends on whether you want to fix the drivers now and practice on KWin, or wait until the last minute to try and support it when you absolutely have to.

            I know which one I'm betting on, given the history of fglrx.

            Comment


            • #51
              Originally posted by markg85 View Post
              Which bug tracker? The amd one? Or the one that was linked to somewhere in this thread?
              http://ati.cchtml.com

              BTW I took a quick look and didn't see any tickets related to this.

              Originally posted by markg85 View Post
              And could you please keep us up to date on the progress? I'm asking because I really want to use either opengl 2 or es in kwin simply because that is supposedly giving better performance on kwin..
              You may have mentioned this earlier, but do the open drivers work for you with kwin ? Their GL ES and EGL support seems to work fairly well these days.

              Generally the open drivers track advances in desktop & consumer apps faster while the proprietary drivers focus much more on pro workstation & compute apps (where you see essentially zero use of GL ES or compositors).
              Last edited by bridgman; 09-10-2011, 09:24 PM.

              Comment


              • #52
                Originally posted by bridgman View Post
                http://ati.cchtml.com

                BTW I took a quick look and didn't see any tickets related to this.



                You may have mentioned this earlier, but do the open drivers work for you with kwin ? Their GL ES and EGL support seems to work fairly well these days.

                Generally the open drivers track advances in desktop & consumer apps faster while the proprietary drivers focus much more on pro workstation & compute apps (where you see essentially zero use of GL ES or compositors).
                --sorry for any typos, writing this using swype on my smartphone--

                Hi john,

                I tried the oss driver and it works will with gles, big pros on that side.
                However, my gpu (the 6870) was blasting all it could and dynpm wasn't helping at all. No fan control there plus the occasionally screen flickering when dynpm was used. Sadly not usable for me. So I had to use the profile method to get my fan down. When put on low the noise was like usual with catalyst thus oke, huur the speed was horrible. Kde was just sluggish when the gpu was in the low profile method so that again was not usable. With that the entire oss gpu.stack became unusable for me so I had to go back to the binary driver and there I had opengl 1 in kwin. And that lead me to making this topic so the rest its history in here.

                So yes, the oss driver works but due to no fan management and poor performance in low profile method that option became non viable for me.

                Hope that clears things up a bit. I for one am certainly waiting to see kwin working well with the binary driver and at the very least opengl 2 thus meaning you guys (amd) should fix direct rendering thus making it fast like david arlied said some pages back Can we expect that to happen I'm the 11.9 release..? Please say yes

                Comment


                • #53
                  OK, thanks. I'm assuming you tried to get a "medium" profile and that didn't work ? That's the normal recommendation for the open drivers, but sometimes it doesn't work if your card has an extremely sparse set of power tables in the BIOS.

                  You keep talking about this as a "bug fix" (implying a small code change correcting a logic or coding error) when it's probably quite a bit more than that. I understand you are probably not joking when you ask about having an enhancement like this implemented and delivered in the 11.9 release but honestly there is zero chance unless it was something initiated a few months ago. As other AMD folks have said multiple times, the releases are pipelined from development through QA so the 11.9 release contents would have been locked down a month or so ago and 11.10 is probably just locking down now other than the last few simple changes.

                  Comment


                  • #54
                    Sorry if I missed something, but what exactly is wrong with Catalyst? I'm running 11.8 on a Radeon 6850 with very good performance on KWin (all effects enabled). Videos play fine, dual-head and head switching work fine, no tearing, and excellent framerates on Amnesia (though it works better if I temporarily disable the compositor pressing Alt+Shift+F12).

                    Comment


                    • #55
                      As I understand it from the discussion so far, the issue is that KWin has to use different code paths with fglrx than those used for other drivers, and so :

                      (a) some effects are probably not available with fglrx (this is a guess, don't think I have actually heard anyone say it)

                      (b) there is a bigger maintenance burden for the KWin developers because of the need to maintain additional code paths (which is a non-trivial issue for pretty much any open source project)

                      There is probably also some kind of performance penalty from taking the older code paths but not sure how significant that is. Anyways, key message is that making additional capabilities available in the fglrx driver would simplify things considerably for the KWin developers and would probably allow them to offer additional features & performance on systems using fglrx.

                      Something like that anyways
                      Last edited by bridgman; 09-11-2011, 11:35 AM.

                      Comment


                      • #56
                        Originally posted by bridgman View Post
                        OK, thanks. I'm assuming you tried to get a "medium" profile and that didn't work ? That's the normal recommendation for the open drivers, but sometimes it doesn't work if your card has an extremely sparse set of power tables in the BIOS.

                        You keep talking about this as a "bug fix" (implying a small code change correcting a logic or coding error) when it's probably quite a bit more than that. I understand you are probably not joking when you ask about having an enhancement like this implemented and delivered in the 11.9 release but honestly there is zero chance unless it was something initiated a few months ago. As other AMD folks have said multiple times, the releases are pipelined from development through QA so the 11.9 release contents would have been locked down a month or so ago and 11.10 is probably just locking down now other than the last few simple changes.
                        I'm certainly not joking. I'm not quite sure but I think I did try the medium profile but that was still to noisy for my taste. So, assuming amd is gonna look into it then the earliest release that has it fixed is 11.11? Then please do get this issue in the internal amd radar! I'd love to see this fixed asap, obviously. And yes, I don't know how much time our work this costs to fix it but hey, they get paid to do exactly that

                        So it's gonna be fixed in 11.11? (yeah, I'm pushing a bit.. I know)

                        @pseus at first everything seemed fine, but my eyes are very sensitive for things that are stuttering even by just a fraction. And after some time I noticed the effects where not running smoothly specially when a konsole window is open as well. With the foss driver it does run smooth but only in the high profile. Note that this "might" also improve in kde 4.8 when all martin's optimizations are in.

                        Comment


                        • #57
                          Originally posted by markg85 View Post
                          I'm certainly not joking.
                          I figured that so didn't give a flippant answer. Given the realities of our (and everyone else's) release cycles it might as well be a joke, just so you know...

                          Originally posted by markg85 View Post
                          I'm not quite sure but I think I did try the medium profile but that was still to noisy for my taste.
                          Please check at your convenience. It would suck if you were missing a good solution today.

                          Originally posted by markg85 View Post
                          So, assuming amd is gonna look into it then the earliest release that has it fixed is 11.11?
                          If someone were to start work on it immediately and the changes were relatively low risk then the earliest would be 11.11. If work has already started it could be sooner. If work starts later or if the changes are high impact & risk it will be later.

                          Originally posted by markg85 View Post
                          Then please do get this issue in the internal amd radar! I'd love to see this fixed asap, obviously.
                          There's a bug tracker for getting things on the internal radar. I am trying to make sure I understand the issue in case there are questions, since the bug tracker tickets rarely have enough detail to be useful to the developers on their own.

                          Originally posted by markg85 View Post
                          And yes, I don't know how much time our work this costs to fix it but hey, they get paid to do exactly that
                          Actually, no, they don't get paid to work on this. They get paid to work on workstation and compute issues, and we try to provide some consumer coverage by supporting Ubuntu releases. This issue doesn't really fit into any of those buckets, although it may at some point in the future. That said, the developers do look at bug tickets and try to work solutions for common problems into their plans even if it's not part of their official jobs.

                          Originally posted by markg85 View Post
                          So it's gonna be fixed in 11.11? (yeah, I'm pushing a bit.. I know)
                          For the lebenty-millionth time, I work on the open source side not the Catalyst side. I have no idea when or if it will be fixed.

                          Comment


                          • #58
                            Originally posted by markg85 View Post
                            @pseus at first everything seemed fine, but my eyes are very sensitive for things that are stuttering even by just a fraction. And after some time I noticed the effects where not running smoothly specially when a konsole window is open as well. With the foss driver it does run smooth but only in the high profile. Note that this "might" also improve in kde 4.8 when all martin's optimizations are in.
                            Well, the problems are in dynpm algorithms. When the efects come in, it should go to "high" profile automatically, so GPU can handle this spike in the GL pipeline at maximum speed. Since this is just a spike, it shouldn't make your fan loud. Someone on this forum had been working on this particular issue, and made a progress. I don't know if it made it to master, though. You can try search the forum.

                            Comment


                            • #59
                              Originally posted by Drago View Post
                              Well, the problems are in dynpm algorithms. When the efects come in, it should go to "high" profile automatically, so GPU can handle this spike in the GL pipeline at maximum speed. Since this is just a spike, it shouldn't make your fan loud. Someone on this forum had been working on this particular issue, and made a progress. I don't know if it made it to master, though. You can try search the forum.
                              As far as i understood it the entire fan management is just not in the code for 6xxx cards.

                              Comment


                              • #60
                                Originally posted by bridgman View Post
                                I figured that so didn't give a flippant answer. Given the realities of our (and everyone else's) release cycles it might as well be a joke, just so you know...



                                Please check at your convenience. It would suck if you were missing a good solution today.



                                If someone were to start work on it immediately and the changes were relatively low risk then the earliest would be 11.11. If work has already started it could be sooner. If work starts later or if the changes are high impact & risk it will be later.



                                There's a bug tracker for getting things on the internal radar. I am trying to make sure I understand the issue in case there are questions, since the bug tracker tickets rarely have enough detail to be useful to the developers on their own.



                                Actually, no, they don't get paid to work on this. They get paid to work on workstation and compute issues, and we try to provide some consumer coverage by supporting Ubuntu releases. This issue doesn't really fit into any of those buckets, although it may at some point in the future. That said, the developers do look at bug tickets and try to work solutions for common problems into their plans even if it's not part of their official jobs.



                                For the lebenty-millionth time, I work on the open source side not the Catalyst side. I have no idea when or if it will be fixed.
                                Thank you for your reply.
                                Last thing to ask you is: Could you put this on the internal AMD radar? Just to get "some" progress into it.
                                I will anoy you from time to time to ask for the status of it hehehe

                                As for testing the medium setting. Will do that as soon as i'm on linux again.

                                Comment

                                Working...
                                X