Page 3 of 8 FirstFirst 12345 ... LastLast
Results 21 to 30 of 78

Thread: AMD, please give us EGL or decent direct rendering.

  1. #21
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,574

    Default

    OK, thanks.

    Quote 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 ?

    Quote 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 at 02:01 AM.

  2. #22
    Join Date
    Oct 2008
    Posts
    3,247

    Default

    Quote 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.

  3. #23
    Join Date
    May 2007
    Posts
    319

    Default

    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.

  4. #24
    Join Date
    Oct 2007
    Posts
    297

    Default

    @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.

  5. #25
    Join Date
    Oct 2008
    Posts
    3,247

    Default

    Quote 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 at 07:16 AM.

  6. #26
    Join Date
    Dec 2010
    Posts
    108

    Default

    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 ;-)

  7. #27
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,574

    Default

    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 at 01:27 PM.

  8. #28
    Join Date
    Dec 2010
    Posts
    108

    Default

    Quote 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 ;-)

  9. #29
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    936

    Default

    Quote 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]

  10. #30
    Join Date
    Oct 2007
    Posts
    321

    Default

    Quote 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 )

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •