Announcement

Collapse
No announcement yet.

AMD, please give us EGL or decent direct rendering.

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

  • #61
    Originally posted by markg85 View Post
    Last thing to ask you is: Could you put this on the internal AMD radar? Just to get "some" progress into it.
    Let me try one more time. I can put things on the internal radar which are within the range of markets and distros we officially support. This is not one of them. A well written bug tracker ticket filed by someone using KWin on a regular basis who can respond to questions & possible solutions can at least get the issue in front of developers, and I may be able to help if there are internal questions raised.

    Originally posted by markg85 View Post
    I will anoy you from time to time to ask for the status of it hehehe
    Bugging me for status may be amusing but WHAT PART OF "I AM NOT INVOLVED WITH THE CATALYST DRIVER" AM I NOT MAKING CLEAR ?

    Thanks,
    John
    Last edited by bridgman; 09-11-2011, 01:55 PM.

    Comment


    • #62
      Originally posted by markg85 View Post
      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.
      Mark. Stop it, man. Can't you understand, that you can ask John about r600,r600g only. He is not in response for Catalyst driver. I guess that with more noise from Linux users, AMD can fix this is issue. But bugging John, is not driving you anywhere.

      Comment


      • #63
        Originally posted by Drago View Post
        But bugging John, is not driving you anywhere.
        It's driving me away from the forums, I guess that's somewhere

        ----------------------------------------

        Let me try to summarize what I think the issues are from a developer perspective :

        1. Default for latest KWin is direct rendering & GL 2 backend, but performance is poor with texture-from-pixmap operations so KWin defaults to indirect rendering

        2. fglrx appears to only expose GL 1.1 support (eg no GLSL) when running indirect so KWin forced to use legacy GL 1 back end and certain effects are not available.

        3. a third back-end using GL ES 2.0 and EGL is available, currently experimental but will be the preferred implementation going forward. The fglrx implementation of GL ES / EGL requires some non-standard packaging and does not appear to work with any distro packages.

        4. even if GL ES / EGL support could be installed successfully, there are problems using it from KWin (and possibly from other EGL apps as well), see summary from Martin :

        "To use GLES/EGL we don't link against libgl and may not use glx. With fglrx we currently would have to resolve the function pointers and still link libgl. Both is not compatible to our existing code base and because of that not possible to add. We also did not consider to spend time on it (in the past and the future) as we expect the same problem as for desktop gl to be present in gles/egl with fglrx."

        The GL ES / EGL backend does appear to be working successfully with the open drivers.

        -----------------------------------

        From an end-user perspective, the primary reported issue is a lack of smoothness when running KDE 4.7 with fglrx via the legacy GL 1 backend. There is a belief/hope from users that KWin operation would be smoother if using GLSL or GL ES 2.0 / EGL but this is only a hypothesis AFAIK. The observed issues could be residual texture-from-pixmap performance issues or something entirely unrelated.

        The secondary end-user issue is that certain effects are unavailable without GLSL, although they do not appear to be commonly used effects. That said, all effects are running with legacy code paths rather than the actively maintained GL 2 code paths in KWin so this is likely to become a bigger problem over time.

        The obvious solution of using the open source drivers is not an option for all users, since some systems do not appear to provide a "mid" power/performance option and the "low" option is sometimes too slow to run KDE with effects smoothly.

        -----------------------------------

        Does that sound about right ?
        Last edited by bridgman; 09-11-2011, 03:25 PM.

        Comment


        • #64
          Thank you John for your summarize. Please stay in this forum. Just don't respond to non-constructive posts. There will always be such, so don't swet.
          So, if Catalyst is so big mess regardging EGL and GLES, can't this issue with dynpm be fixed. If there is no "mid" profile in VBIOS, I guess it can be introduced to kernel, by other means. I have presistent feeling that we already discussed this in the forum. Someone found that dinpm didn't work quite as intended, and some video card vednors didn't provide all performace profiles. The guy then added by them from /proc(or /sys, I don't remember) interface. I will try to find this thread.
          This power managment issue will get more annoying in the future, especially with explosion of this little APUs of yours. I will get mine in 2 weeks, also.

          EDIT: Here is the thread: http://phoronix.com/forums/showthrea...Catalyst/page5

          User: ahlaht
          Last edited by Drago; 09-11-2011, 04:03 PM.

          Comment


          • #65
            "I AM NOT INVOLVED WITH THE CATALYST DRIVER"
            hehe, sorry bridgman but you're just "our" point of entry to AMD
            Anyway, i get it.

            I just hope that it gets fixed this year..
            Or to get r600g with decent dynpm (no flickering and my fans not blasting out loud) is all i need there to use it. The performance - as it is now - is already fine for desktop usage.

            Comment


            • #66
              Originally posted by bridgman View Post
              It's driving me away from the forums, I guess that's somewhere

              ----------------------------------------
              I doubt any members of the comunnity are meaning to drive you away from the forum. However, the methods for communication from end users to AMD is very limited.

              Originally posted by bridgman View Post
              Let me try to summarize what I think the issues are from a developer perspective :

              1. Default for latest KWin is direct rendering & GL 2 backend, but performance is poor with texture-from-pixmap operations so KWin defaults to indirect rendering

              2. fglrx appears to only expose GL 1.1 support (eg no GLSL) when running indirect so KWin forced to use legacy GL 1 back end and certain effects are not available.
              These two points probably would be helped if there was more methods for end users available. However, due to the lacking driver features most developers and end users wind up telling others to simply go nvidia with no questions asked when choosing video cards for linux.

              Originally posted by bridgman View Post
              3. a third back-end using GL ES 2.0 and EGL is available, currently experimental but will be the preferred implementation going forward. The fglrx implementation of GL ES / EGL requires some non-standard packaging and does not appear to work with any distro packages.

              4. even if GL ES / EGL support could be installed successfully, there are problems using it from KWin (and possibly from other EGL apps as well), see summary from Martin :

              "To use GLES/EGL we don't link against libgl and may not use glx. With fglrx we currently would have to resolve the function pointers and still link libgl. Both is not compatible to our existing code base and because of that not possible to add. We also did not consider to spend time on it (in the past and the future) as we expect the same problem as for desktop gl to be present in gles/egl with fglrx."

              The GL ES / EGL backend does appear to be working successfully with the open drivers.
              Improving EGL/ GL ES Will probably attract mobile Developers, however overcoming the NVidia prejudices is going to be tough.

              Originally posted by bridgman View Post
              -----------------------------------

              From an end-user perspective, the primary reported issue is a lack of smoothness when running KDE 4.7 with fglrx via the legacy GL 1 backend. There is a belief/hope from users that KWin operation would be smoother if using GLSL or GL ES 2.0 / EGL but this is only a hypothesis AFAIK. The observed issues could be residual texture-from-pixmap performance issues or something entirely unrelated.

              The secondary end-user issue is that certain effects are unavailable without GLSL, although they do not appear to be commonly used effects. That said, all effects are running with legacy code paths rather than the actively maintained GL 2 code paths in KWin so this is likely to become a bigger problem over time.

              The obvious solution of using the open source drivers is not an option for all users, since some systems do not appear to provide a "mid" power/performance option and the "low" option is sometimes too slow to run KDE with effects smoothly.

              -----------------------------------

              Does that sound about right ?
              Yes, this is actually about right. Also I'd add that end users will give really poor feedback, while developers can figure out more detailed bug reports. I already have one good example that the closed driver team needs to look at. That's the video sync extension that says it is supported, but is clearly broken. The Mesa drivers handle the extension flawlessly on ATI graphics cards, but when you look at fglrx the extension has always been broken ( 3+ years ).

              Actually, on the Open Source Drivers, it'd be nice to see some simple support for Crossfire/Hybrid graphics considering that affordable laptops now include a Radeon HD6720G2 (HD 6650M dedicated and 6520G integrated) in laptops. A good example is the ASUS K53TA laptop.

              Actually, End users really value Wine support. Mesa has better support in some ways than the proprietary driver, however, it'll be good to get better support testing with verifying that the various newer games that show gold status on the wine application database work.

              Comment


              • #67
                1 more thing

                Most people here are complaining about KWin 4.7+, but I think it affects Gnome Shell just as much if not more. I don't think they have a fallback for fglrx like KWin does, and they just disable compositing completely. (not sure about that)

                It might make sense to emphasize that in any bug reports to AMD, because I imagine they care a lot more about Red Hat than all the consumer-focused distros that use KDE.

                Comment


                • #68
                  On a related note

                  Have all the devs basically given up on power management in the OSS drivers? Or is there a plan to return to that after they've finished working on other tasks?

                  That seems to be the #1 blocker to using the OSS drivers now, with people complaining about power use and loud fans when running full speed and performance at the low power settings.

                  Comment


                  • #69
                    Originally posted by smitty3268 View Post
                    Most people here are complaining about KWin 4.7+, but I think it affects Gnome Shell just as much if not more. I don't think they have a fallback for fglrx like KWin does, and they just disable compositing completely. (not sure about that)

                    It might make sense to emphasize that in any bug reports to AMD, because I imagine they care a lot more about Red Hat than all the consumer-focused distros that use KDE.
                    Gnome 3 works nice, fast and stable on fglrx here. So I guess you are wrong about that.

                    Comment


                    • #70
                      Originally posted by tball View Post
                      Gnome 3 works nice, fast and stable on fglrx here. So I guess you are wrong about that.
                      So does kwin 4.7 here. I just recently switched back to fglrx and was surprised how smooth everything was. This thread confuses me. :/
                      How can I find out which kwin-backend I'm using?

                      Comment


                      • #71
                        Originally posted by bridgman View Post
                        It's driving me away from the forums, I guess that's somewhere

                        1. Default for latest KWin is direct rendering & GL 2 backend, but performance is poor with texture-from-pixmap operations so KWin defaults to indirect rendering

                        2. fglrx appears to only expose GL 1.1 support (eg no GLSL) when running indirect so KWin forced to use legacy GL 1 back end and certain effects are not available.
                        2 isn't a surprise, GLX protocol has never been specified for GL2.0, esp the shader extensions.

                        Dave.

                        Comment


                        • #72
                          Originally posted by airlied View Post
                          2 isn't a surprise, GLX protocol has never been specified for GL2.0, esp the shader extensions.
                          Yeah, that's what I was wondering about (wasn't sure either way)... thanks.

                          Comment


                          • #73
                            Originally posted by smitty3268 View Post
                            Most people here are complaining about KWin 4.7+, but I think it affects Gnome Shell just as much if not more. I don't think they have a fallback for fglrx like KWin does, and they just disable compositing completely. (not sure about that).
                            My (casual) understanding was that with Gnome Shell the issue was graphical corruption, but maybe there are other issues as well ?

                            Originally posted by smitty3268 View Post
                            Have all the devs basically given up on power management in the OSS drivers? Or is there a plan to return to that after they've finished working on other tasks? That seems to be the #1 blocker to using the OSS drivers now, with people complaining about power use and loud fans when running full speed and performance at the low power settings.
                            There doesn't seem to be much community interest so we may have to give it another push ourselves. Seems like some kind of "fake mid" profile would be a good next step.

                            Comment


                            • #74
                              Originally posted by bridgman View Post
                              My (casual) understanding was that with Gnome Shell the issue was graphical corruption, but maybe there are other issues as well ?
                              Yes, the Gnome 3 shell does have graphical Corruption on the Upper bar that causes text to become unreadable.

                              Originally posted by bridgman View Post
                              There doesn't seem to be much community interest so we may have to give it another push ourselves. Seems like some kind of "fake mid" profile would be a good next step.
                              A "fake mid" profile could simply be adding the gpu speed control code into the open drivers. However, from this it'd be set the gpu at about 50% of it rated max speed.

                              Anyways, There is two major features that i can see that would be useful to have as xorg extensions. The first extension is to improve Multi-Monitor configuration hotplug support within the xserver. The only reason i state this is that this is a major feature for mobile users. I personally find myself using three main modes. Built-In display, HDMI Output only, and then Both. As for both, it'd be nice to be able to change from Display Spanning ( Big Desktop ) to Multi-Desktop Setup ( Separate Desktops ) without having to reboot in any fashion. The other extension is about Multi-GPU support improvements. After all, it'd be nice to switch graphics card configurations without having to restart the xserver. A a good example of this is to go from the Integrated Graphics (Intel, or Low end Radeon) to a dedicated GPU. This is also a major focus on Mobile users, however it probably will find some use for desktop and workstation users also.

                              Comment


                              • #75
                                Decent direct rendering just arrived: http://www2.ati.com/drivers/hotfix/c...x86.x86_64.zip
                                Check this with KWIN_DIRECT_GL=1 - almost 60 fps!

                                Comment

                                Working...
                                X