AMD, please give us EGL or decent direct rendering.

[bridgman]

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.

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

[Drago]

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.

[bridgman]

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 ?

[Drago]

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

[markg85]

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

[Dandel]

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.

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.

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.

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

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.

[smitty3268]

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.

[smitty3268]

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.

[tball]

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.

[Zhick]

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?