AMD, please give us EGL or decent direct rendering.

[bridgman]

OK, thanks.

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 ?

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

[smitty3268]

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.

[airlied]

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.

[markg85]

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

[smitty3268]

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.

[mgraesslin]

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

[bridgman]

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.

[mgraesslin]

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

[entropy]

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]

[Dandel]

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 )