Announcement

Collapse
No announcement yet.

AMD, please give us EGL or decent direct rendering.

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

  • AMD, please give us EGL or decent direct rendering.

    Hi,

    http://blog.mageprojects.com/2011/09...lyst-and-mesa/

    -- The short story --
    Right now KWIN falls back to OpenGL 1.x with catalyst due to direct rendering being screwed up or something..? don't know the inner details just that direct rendering is to blame.

    For opengles kwin needs egl. The catalyst drivers don't provide that (or do they with some magic symbolic links?) .. Please provide EGL.

    I really just want to run kde/kwin as they are supposed to do. Somehow AMD always manages to really get the blood under my nails in this stuff. Please AMD, QUIT putting out new OpenGL revisions if the older things aren't even working.. Like direct rendering, glsl, and egl. I really just have that stuff all working perfectly with opengl 2.3 instead of having a severely crippled opengl 4.something.

    Regards,
    Mark

  • #2
    Yea fglrx sucks at opengl 2 support. But with fglrx driver I have perfectly smooth desktop effects in KDE 4.6.5. This is what I did:

    1) Turned off blur.
    2) Turned off vsync in kwin
    3) Turned off all oxygen animations (alt+f2 and type oxygen-settings and in widget style and window decorations tabs turn off animations)
    4) Change graphics system to raster. Install kde-config-qt-graphicssystem in Kubuntu or find it on http://kde-apps.org/content/show.php?content=129817. Then go to SystemSettings>Qt graphics system and change to raster. Log out and log back in and test. Desktop effects should be smoother and whole desktop should be much more resposive and faster (because of raster). At least in my experiance it is faster

    And yes, it would be great if AMD fixes the driver and if I could use kwin opengl2 backend

    Comment


    • #3
      There is a fully functionaly copy of EGL that exists within FGLRX, however, the libraries are not public yet. The actual copy of EGL (Including OpenGL ES 2.0) is available by loading "libgl.so.1", and then loading the address for eglGetProcAddress . This should work for all distributions, however, in my experience it fails when distribution packages are involved.


      Ubuntu 10.10 (amd64) - Distro Package (11.5 to 11.8) - Fails
      Ubuntu 10.10 (amd64) - Direct install ( 11.5 to 11.8) - works ( Installed without generating system packages )
      Sabayon 6 ( amd64 ) - Distribution package (11.6 ) - Driver failure ( A-series laptop )
      Sabayon 6 (amd64 ) - distribution package ( 11.8) - Fails, but for same reason as the other distro packages are.

      Comment


      • #4
        Originally posted by schnelle View Post
        Yea fglrx sucks at opengl 2 support. But with fglrx driver I have perfectly smooth desktop effects in KDE 4.6.5. This is what I did:

        1) Turned off blur.
        2) Turned off vsync in kwin
        3) Turned off all oxygen animations (alt+f2 and type oxygen-settings and in widget style and window decorations tabs turn off animations)
        4) Change graphics system to raster. Install kde-config-qt-graphicssystem in Kubuntu or find it on http://kde-apps.org/content/show.php?content=129817. Then go to SystemSettings>Qt graphics system and change to raster. Log out and log back in and test. Desktop effects should be smoother and whole desktop should be much more resposive and faster (because of raster). At least in my experiance it is faster

        And yes, it would be great if AMD fixes the driver and if I could use kwin opengl2 backend
        Thanks for thinking with me. However i don't want to cripple KDE for catalyst when i have a high end card. Specially turning off animations is just a no-go for me. I like the animation

        Originally posted by Dandel View Post
        There is a fully functionaly copy of EGL that exists within FGLRX, however, the libraries are not public yet. The actual copy of EGL (Including OpenGL ES 2.0) is available by loading "libgl.so.1", and then loading the address for eglGetProcAddress . This should work for all distributions, however, in my experience it fails when distribution packages are involved.


        Ubuntu 10.10 (amd64) - Distro Package (11.5 to 11.8) - Fails
        Ubuntu 10.10 (amd64) - Direct install ( 11.5 to 11.8) - works ( Installed without generating system packages )
        Sabayon 6 ( amd64 ) - Distribution package (11.6 ) - Driver failure ( A-series laptop )
        Sabayon 6 (amd64 ) - distribution package ( 11.8) - Fails, but for same reason as the other distro packages are.
        Ohh interesting, i did do symlinking to that for opegles but not for egl. Gonna give that a try.

        Comment


        • #5
          Oke, the result is and remains the same. AMD needs to fix direct rendering nomather what option you choose or try.

          Comment


          • #6
            It would be interesting if an amd fellow could reply in here about the state of direct rendering, why it's so problematic and what is gonna be done about it. It really sucks to use opengl 1.x when the card supports 4.x and is in the high end range (6870) ...

            Please "amd", respond in here!

            Comment


            • #7
              How did we get from GL ES / EGL (which AFAIK might still need some special handling) to direct rendering in general (which AFAIK works fine) ? Is this because you get a "direct rendering" error message when trying to use the GL ES renderer in KWin ?

              Comment


              • #8
                Originally posted by bridgman View Post
                How did we get from GL ES / EGL (which AFAIK might still need some special handling) to direct rendering in general (which AFAIK works fine) ? Is this because you get a "direct rendering" error message when trying to use the GL ES renderer in KWin ?
                Well, the issue is that the kwin developer says it sucks thus falls back to opengl 1.x. Direct rendering is supposedly to slow (read bugged) to be used for a decorations application. Don't ask me why, i'm not the kwin developer but and i can't enable something that isn't even implemented.

                So you and the kwin developers should really chat sometime in some irc room since this is just.. way to embarrassing. pff, opengl 1

                As for the link to direct rendering. I've been told that direct rendering is bugged in opengl and opengles thus that is one reason why it can't be used. Another one is that the fglrx driver doesn't come with all the opengles libs/headers thus kwin would need to be linked against libgl. Yet another thing the kwin devs won't consider.

                Comment


                • #9
                  Originally posted by bridgman View Post
                  How did we get from GL ES / EGL (which AFAIK might still need some special handling) to direct rendering in general (which AFAIK works fine) ?
                  Yes, there some special handling to get at the GL ES/EGL, however, this does not work properly.

                  Install from package manger is just plain failing when using Ubuntu 10.10 ( amd64, Catalyst 11.5 and up ), Sabayon Linux ( amd64, Catalyst 11.8 ), and probably other distributions. The symptom is always the same when i run from the generated packages... The dlsym call will allow eglGetProcAddress to work, but when i go to use eglGetProcAddress to get any other functions the program will fail to get the address of the function because the use of eglGetProcAddress causes a segfault.

                  Now as for a comparison, using the same program with the official installer works.

                  anyways, i know that there is some library shuffles on most distributions, and both of these have that...

                  sabayon linux places libGL.so.1.2 in the following locations: ( fglrx_dri.so is in a standard location, namely /usr/lib/dri/fglrx_dri.so )
                  /usr/lib/opengl/ati/lib/libGL.so.1.2
                  /usr/lib32/opengl/ati/lib/libGL.so.1.2
                  /usr/lib64/opengl/ati/lib/libGL.so.1.2

                  now as for Ubuntu, I know they use the location /usr/lib(arch)/fglrx/libGL.so.1.2
                  Originally posted by bridgman View Post
                  Is this because you get a "direct rendering" error message when trying to use the GL ES renderer in KWin ?
                  I haven't tried kwin, but i've tried Gnome 2.3 and XFCE 4.x, and the openGL ES does not work on either when the driver is installed via the package manger.

                  Actually, I saw a bug report on this and it has a sample of openGL ES that is modified from the Official demo that amd released a while back for windows. ( Link to unofficial bug report page )

                  Comment


                  • #10
                    Originally posted by Dandel View Post
                    Yes, there some special handling to get at the GL ES/EGL, however, this does not work properly.

                    Install from package manger is just plain failing when using Ubuntu 10.10 ( amd64, Catalyst 11.5 and up ), Sabayon Linux ( amd64, Catalyst 11.8 ), and probably other distributions. The symptom is always the same when i run from the generated packages... The dlsym call will allow eglGetProcAddress to work, but when i go to use eglGetProcAddress to get any other functions the program will fail to get the address of the function because the use of eglGetProcAddress causes a segfault.

                    Now as for a comparison, using the same program with the official installer works.

                    anyways, i know that there is some library shuffles on most distributions, and both of these have that...

                    sabayon linux places libGL.so.1.2 in the following locations: ( fglrx_dri.so is in a standard location, namely /usr/lib/dri/fglrx_dri.so )
                    /usr/lib/opengl/ati/lib/libGL.so.1.2
                    /usr/lib32/opengl/ati/lib/libGL.so.1.2
                    /usr/lib64/opengl/ati/lib/libGL.so.1.2

                    now as for Ubuntu, I know they use the location /usr/lib(arch)/fglrx/libGL.so.1.2

                    I haven't tried kwin, but i've tried Gnome 2.3 and XFCE 4.x, and the openGL ES does not work on either when the driver is installed via the package manger.

                    Actually, I saw a bug report on this and it has a sample of openGL ES that is modified from the Official demo that amd released a while back for windows. ( Link to unofficial bug report page )
                    Just for clarity, the bug url is: http://ati.cchtml.com/show_bug.cgi?id=126

                    Comment


                    • #11
                      Thanks, markg85. That bug ticket suggests that packaging challenges are major issue (although I don't know whether the packaging challenges are a consequence of something we are doing, of course). When we were playing with EGL on the open drivers we tripped over many of the same things -- that EGL isn't as portable as one might think unless you code with very specific options (which most samples do not).

                      I'm still trying to understand the references to direct rendering being broken though... I get the GL ES / EGL challenges but I don't get the direct rendering complaints yet. Are you talking specifically about direct rendering usage by a compositor (which has always been a bit of a touchy case IIRC) or direct rendering in general ?
                      Last edited by bridgman; 09-07-2011, 11:46 AM.

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        Thanks, markg85. That bug ticket suggests that packaging challenges are major issue (although I don't know whether the packaging challenges are a consequence of something we are doing, of course). When we were playing with EGL on the open drivers we tripped over many of the same things -- that EGL isn't as portable as one might think unless you code with very specific options (which most samples do not).

                        I'm still trying to understand the references to direct rendering being broken though... I get the GL ES / EGL challenges but I don't get the direct rendering complaints yet. Are you talking specifically about direct rendering usage by a compositor (which has always been a bit of a touchy case IIRC) or direct rendering in general ?
                        Hi, I'm taking about direct rendering in composting. In this case kwin specific since I don't know the states of gnome, xfce and others.

                        Comment


                        • #13
                          Originally posted by markg85 View Post
                          Hi, I'm taking about direct rendering in composting. In this case kwin specific since I don't know the states of gnome, xfce and others.
                          Thanks. Next question -- are we talking about running apps using direct rendering through a compositor (which IIRC should work pretty well these days) or having the compositor itself use direct rendering ?

                          My impression was that compositors tended to use indirect rendering in order to simplify interaction with X (details outside my current level of knowledge) and that was one of the primary reasons for implementing AIGLX (Accelerated Indirect...) in the first place).

                          Comment


                          • #14
                            Originally posted by bridgman View Post
                            Thanks. Next question -- are we talking about running apps using direct rendering through a compositor (which IIRC should work pretty well these days) or having the compositor itself use direct rendering ?

                            My impression was that compositors tended to use indirect rendering in order to simplify interaction with X (details outside my current level of knowledge) and that was one of the primary reasons for implementing AIGLX (Accelerated Indirect...) in the first place).
                            I'm not sure it has anything to do with direct rendering (although KWin is able to do both direct and indirect, and it's been mentioned that fglrx only works halfway acceptably in the indirect mode). You should really get with the KWin developers and figure out what the problem is.

                            I know they have blacklisted fglrx from using OpenGL 2 features because of severe performance problems, and have it just using the old fixed function pipeline. I think other compositors have complained of the same issue, although i'm not 100% sure of that. It could just be something like TFP being too slow when using GLSL or something like that, I have no clue.

                            I think the original poster then brought up EGL as an alternative to the OpenGL 2 support, although it's not clear to me that it would be any different. It could have the same problems.

                            Comment


                            • #15
                              Yeah, it's a little complicated for the K* devs because "we" (the open source community including AMD folks) is recommending the intersection set of GL ES and GL2 for the open source drivers (sometimes referred to as the GL ES 2.0 subset of GL 2.x), but "we" (AMD) are recommending regular GL 2 with the proprietary drivers.

                              GL ES / EGL with the proprietary drivers still seems to have trouble making it through distro packaging systems because it's relatively new and (AFAICS) needs a bit of non-standard usage.

                              Comment

                              Working...
                              X