AMD, please give us EGL or decent direct rendering.

[markg85]

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

[schnelle]

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

[Dandel]

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.

[markg85]

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

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.

[markg85]

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

[markg85]

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!

[bridgman]

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 ?

[markg85]

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.

[Dandel]

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

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 )

[markg85]

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