Announcement

Collapse
No announcement yet.

AMD, please give us EGL or decent direct rendering.

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

  • #16
    Originally posted by bridgman View Post
    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.
    I'm not sure i understand what you are trying to say here. It's not complicated - the Mesa drivers and NVidia drivers work fine. Fglrx works if they stick to the fixed function hardware, but there is some problem with programmable shaders used by compositors - not just Kwin but also others. Seems pretty simple to me.

    Comment


    • #17
      Originally posted by smitty3268 View Post
      I'm not sure i understand what you are trying to say here. It's not complicated - the Mesa drivers and NVidia drivers work fine. Fglrx works if they stick to the fixed function hardware, but there is some problem with programmable shaders used by compositors - not just Kwin but also others. Seems pretty simple to me.
      If fglrx is not working with GL 2.x (rather than GL ES 2.0) then I think we want to know what isn't working. The discussion keeps going back to "direct rendering" when I try to get clarity on that, and I'm not sure how direct rendering fits into the equation here. This seems like an API thing rather than a direct/indirect thing but it's hard to be sure.

      Comment


      • #18
        Originally posted by bridgman View Post
        If fglrx is not working with GL 2.x (rather than GL ES 2.0) then I think we want to know what isn't working. The discussion keeps going back to "direct rendering" when I try to get clarity on that, and I'm not sure how direct rendering fits into the equation here. This seems like an API thing rather than a direct/indirect thing but it's hard to be sure.
        As i said, I don't think it has anything to do with direct rendering. I think that's a completely separate issue. I think it might have something to do with slow texture-from-pixmap calls in GL2, but I'm not really sure why i think that. You'd need to talk to the developers for more information.

        Or better yet, just have one of the fglrx devs fire up KDE and set the necessary parameters. I'm sure they'd see exactly what the problem was.

        Comment


        • #19
          Still trying to understand if this is a GL ES issue or a GL issue. If someone can identify what GL function or sequence appears to be misbehaving it's not that hard to get a developer looking at it. If the ask is basically "go become a KDE/KWin developer and learn the internals then futz around with settings until you see a problem" that's a harder sell.
          Last edited by bridgman; 09-08-2011, 12:42 AM.

          Comment


          • #20
            Originally posted by bridgman View Post
            Still trying to understand if this is a GL ES issue or a GL issue.
            OK, let me try to sum up the situation if i can.

            KWin has 3 backends it can use. OpenGL 1 (legacy), OpenGL 2 (which i think is restricted to using stuff that is also present in GL ES 2), and a GL ES 2.0 backend. As I understand it, the GL2 and GL ES2.0 backends are quite similar in what they do and how they do it.

            On the desktop, Mesa and NVidia drivers default to GL2. fglrx is blacklisted to only use GL1 because the new backend is too slow on that driver. ES2.0 support is currently experimental and not default anywhere, but in the future it is expected to be used by - mobile devices, possibly newer Mesa releases, and definitely Wayland when it gets done.

            The original complaint here was that the new GL 2 backend didn't work very well. He was saying alternatively, if you could fix the EGL requirement then maybe the ES2.0 backend would work instead. I'm not actually sure if that would fix the problem being encountered or if it would have the same issues, and neither does he. I don't think anyone has actually tried it or knows.

            Then I think he mixed in a complaint about direct rendering - that is also an issue, but I think a completely separate one. Kwin will work in indirect mode as well as direct - fglrx requires indirect to work, but I don't think that's necessarily a big problem. If you could get that fixed in direct mode, obviously, that would be a bonus.

            I left a comment on the KWin developers blog asking about exactly what is causing them to blacklist fglrx from the GL2 backend, but I don't really have any idea if he will get back to me or not. I don't know if he reads those comments on old posts or not. I'm sure if someone from AMD (like you) posted a message on a KWin mailing list somewhere and mentioned you were interested in improving the fglrx drivers, you would certainly get lots of feedback as to exactly what the problem is. Barring that, I'm not sure how much help you will get on Phoronix, unless as I said he finds my comment and gets back to me, then i will post that information here.

            Comment


            • #21
              OK, thanks.

              Originally posted by smitty3268 View Post
              On the desktop, Mesa and NVidia drivers default to GL2. fglrx is blacklisted to only use GL1 because the new backend is too slow on that driver.
              Which new backend ? I was under the impression that the GL ES / EGL backend was the new one, is the GL2 one new as well ?

              Originally posted by smitty3268 View Post
              The original complaint here was that the new GL 2 backend didn't work very well. He was saying alternatively, if you could fix the EGL requirement then maybe the ES2.0 backend would work instead. I'm not actually sure if that would fix the problem being encountered or if it would have the same issues, and neither does he. I don't think anyone has actually tried it or knows.
              AFAIK we are recommending GL rather than GL ES / EGL for the fglrx driver. The "GL ES subset of GL2" recommendation was primarily for 3xx-5xx hardware with open source drivers, where the driver exposed GL2 caps in order to run more apps but because the hardware was DX9 rather than GL2 (GL2 needs a bit more in the HW than DX9 but came out after the 3xx-5xx HW was designed) the driver couldn't be completely compliant with GL2 without falling back to software and becoming real slow on many common apps. GL ES 2.0 aligns better with DX9 HW capabilities than GL 2 does. Of course this is all irrelevent for fglrx which starts support with DX10 HW.

              Am I being naive expecting a bug report that says "we are expecting A from this sequence of OpenGL commands but we are actually seeing B" ?
              Last edited by bridgman; 09-08-2011, 01:01 AM.

              Comment


              • #22
                Originally posted by bridgman View Post
                Which new backend ? I was under the impression that the GL ES / EGL backend was the new one, is the GL2 one new as well ?
                Yes, they are both new to KDE 4.7. The EGL backend is still experimental, while the GL2 backend is the new default (except for fglrx). They apparently are "identical to more than ~ 95 %" and the difference is mostly EGL vs GLX and EGL_KHR_image_pixmap vs TFP.

                Here is some information from the dev: http://blog.martin-graesslin.com/blo...ces-explained/

                AFAIK we are recommending GL rather than GL ES / EGL for the fglrx driver. The "GL ES subset of GL2" recommendation was primarily for 3xx-5xx hardware with open source drivers, where the driver exposed GL2 caps in order to run more apps but because the hardware was DX9 rather than GL2 (GL2 needs a bit more in the HW than DX9 but came out after the 3xx-5xx HW was designed) the driver couldn't be completely compliant with GL2 without falling back to software and becoming real slow on many common apps. GL ES 2.0 aligns better with DX9 HW capabilities than GL 2 does. Of course this is all irrelevent for fglrx which starts support with DX10 HW.
                GL2 is what they are trying to use with fglrx for now, and failing. There is no problem when using the Mesa drivers.

                Am I being naive expecting a bug report that says "we are expecting A from this sequence of OpenGL commands but we are actually seeing B" ?
                Maybe. From what I can tell, the KWin developers are pretty bad at reporting these issues upstream. That said, I would hope that somebody at AMD would care enough about it to make the slight effort of sending 1 email to the kwin mailing list.

                Or, as i said, just starting KDE 4.7 up, using the graphical options to select the GL2 backend, and watching the driver to see what call is taking so long. I imagine it is probably pretty easy to spot, although I don't know what kind of tools you have to debug the driver.

                Comment


                • #23
                  fglrx has broken texture from pixmap semantics in a direct rendered context is what I think people are trying to say.

                  it either does it really slowly or it does it wrong,

                  though I've tried g-s with fglrx and it seems to be at least fast, just misrendered.

                  Comment


                  • #24
                    @all

                    I've mailed Matrin (the main kwin developer) to notify him of this topic. I'm hoping he will either reply in here or contact bridgman directly.
                    There sure is some constructive talk going on in here and i like the willingness i see from bridgman Good job!

                    As for direct rendering. All i know is that it's an issue right now. I don't know the details behind it but i'm guessing the post above me from airlied is spot on.

                    Please do keep an eye on this topic since i'd hate to see this die and resulting in nothing gets changed..

                    @bridgman your bug report is for certainly some part here: http://ati.cchtml.com/show_bug.cgi?id=126 As for more, please do subscribe to https://mail.kde.org/mailman/listinfo/kde-core-devel and make a topic there. You will get the feedback you want/need and probably a lot more. If you subscribe and don't want to make a topic i can do it for you Gladly if it gets the ball rolling.

                    Comment


                    • #25
                      Originally posted by airlied View Post
                      fglrx has broken texture from pixmap semantics in a direct rendered context is what I think people are trying to say.

                      it either does it really slowly or it does it wrong,

                      though I've tried g-s with fglrx and it seems to be at least fast, just misrendered.
                      This is almost certainly it. Like i said, I didn't really know what i was talking about.

                      Kwin with OpenGL 2 may require a direct rendering context to work. I saw that to test it with fglrx, you have to run it with KWIN_DIRECT_GL=1 set.
                      Last edited by smitty3268; 09-08-2011, 06:16 AM.

                      Comment


                      • #26
                        As I was asked to comment on this thread, I do so, although after reading through the thread there is nothing new which I can add.

                        Why does KWin use GL 1.x for fglrx?
                        Because that's what fglrx provides when running an indirect context. Which leads us to the question:

                        Why do we use an indirect context for fglrx?
                        Because direct rendering is too slow to be the default.

                        But I really, really, really want to use direct rendering with fglrx!
                        Just use the environment variable KWIN_DIRECT_GL=1 and give it a try. I did very often when the radeon driver was not working for me and it's no joy.

                        So what about GLES?
                        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.

                        But I really, really want GLES!
                        So why don't you just install the radeon driver which is currently the best supported driver in KWin?

                        But I really, really want fglrx!
                        I'm sorry but for an open source project it is not rational to invest time for a proprietary driver if an equally good or even better free driver exists. We have to prioritize. If someone wants to spend money on it, it becomes a different issue ;-)

                        Comment


                        • #27
                          Martin, thanks very much. That does clarify things for me a lot.

                          I wasn't aware that fglrx limited GL level to 1.x when running indirect, for example. The driver part of my job at AMD is on the open source side so I normally use the open drivers

                          It's probably also fair to say that while we expected there would be interest in using direct rendering for compositors it wasn't obvious that the level of interest was already at the "really really want" level.
                          Last edited by bridgman; 09-08-2011, 12:27 PM.

                          Comment


                          • #28
                            Originally posted by bridgman View Post
                            It's probably also fair to say that while we expected there would be interest in using direct rendering for compositors it wasn't obvious that the level of interest was already at the "really really want" level.
                            Yes it's a rather new requirement. We have had requests for GLSL effects (e.g. invert) with fglrx since 4.0 (e.g. Bug 173556). But since the radeon driver improved so much (thanks for that ) the requests have become less frequent and also not an issue for us anymore. Since 4.7 we now have the new GL 2 only backend which gives some performance improvements, but isn't available for fglrx users. From functionality side there is hardly any difference. ARB shaders are also supported with the indirect context which means that only the effects which require GLSL are not supported. At the moment that are only invert, cylinder and sphere and I dare to question the usefulness of those ;-)

                            Comment


                            • #29
                              Originally posted by mgraesslin View Post
                              Why do we use an indirect context for fglrx?
                              Because direct rendering is too slow to be the default.

                              But I really, really, really want to use direct rendering with fglrx!
                              Just use the environment variable KWIN_DIRECT_GL=1 and give it a try. I did very often when the radeon driver was not working for me and it's no joy.
                              Hum, is that any different from using the "System Settings" facility?

                              System Settings -> Configure desktop effects -> Advanced

                              If I check "Disable functionality checks" and "Enable direct rendering" I cannot
                              see any performance degradation with direct rendering vs. indirect rendering.

                              [Radeon 4850, Catalyst 11.8, kwin 4.7.1]

                              Comment


                              • #30
                                Originally posted by bridgman View Post
                                Martin, thanks very much. That does clarify things for me a lot.

                                I wasn't aware that fglrx limited GL level to 1.x when running indirect, for example. The driver part of my job at AMD is on the open source side so I normally use the open drivers

                                It's probably also fair to say that while we expected there would be interest in using direct rendering for compositors it wasn't obvious that the level of interest was already at the "really really want" level.
                                Yes, I do agree that having OpenGL ES/EGL working properly on ati drivers is really important. However, there's also other things that are "really really want" level. This is things like End users wanting what runs on Nvidia cards with Wine to also work on AMD/ATI cards.

                                a key example of this is how broken the api is for Unreal engine 3 based games...

                                see: http://ati.cchtml.com/show_bug.cgi?id=54 ( re-reported bug, but still present in Catalyst 11.8, and it's been known to be a problem since at least Catalyst 10.5 )
                                Secondary: http://bugs.winehq.org/show_bug.cgi?id=23048 ( winehq bug report over a year ago )

                                Comment

                                Working...
                                X