I am using Arch with xf86-video-ati 6.13.2-1 and KDE 4.5.2

I have the following issue with openGL http://www.youtube.com/watch?v=qXjBbBbvPCY

If I use xrender instead of openGL, the windows zoom out and in or minimize and maximize really slowly.

Apart from having to add LIBGL_ALWAYS_INDIRECT=1, is there a way to fix this?

Are you using the open source or proprietary ATi drivers?

bcooksley wrote:Are you using the open source or proprietary ATi drivers?

I am using the xf86-video-ati driver, which is the open source one. Along with xorg 1.9

boast wrote:I am using Arch with xf86-video-ati 6.13.2-1 and KDE 4.5.2

I have the following issue with openGL http://www.youtube.com/watch?v=qXjBbBbvPCY

If I use xrender instead of openGL, the windows zoom out and in or minimize and maximize really slowly.

Apart from having to add LIBGL_ALWAYS_INDIRECT=1, is there a way to fix this?

I had the same exact problem as yours using the opensource radeon drivers (xf86-video-ati [extra]) with my x2300 mobility radeon card. I think, however, that the problem lies in the mesa package found in [extra], as the opengl version is 1.5. The one in testing is:

Code: Select all

OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RV515
OpenGL version string: 2.1 Mesa 7.9

Using the mesa packages in [testing] eliminated the problem I had. It is funny that opengl 1.5 worked fine for kwin in 4.5.0 and 4.5.1, but compiled mesa-gallium-git packages threw up a bunch of errors (black boxes in present windows and taskbar thumbnails). Now it is the reverse in my case. I believe someone reported a bug on this earlier and apparently kwin 4.5.2 supports gallium. So, just update your mesa packages and xf86-video-ati from testing. Also install testing/mesa-demos if you want glxinfo, glxgears etc. Apparently some programs like xbmc won't run unless glxinfo is available.

ssri wrote:

boast wrote:I am using Arch with xf86-video-ati 6.13.2-1 and KDE 4.5.2

I have the following issue with openGL http://www.youtube.com/watch?v=qXjBbBbvPCY

If I use xrender instead of openGL, the windows zoom out and in or minimize and maximize really slowly.

Apart from having to add LIBGL_ALWAYS_INDIRECT=1, is there a way to fix this?

I had the same exact problem as yours using the opensource radeon drivers (xf86-video-ati [extra]) with my x2300 mobility radeon card. I think, however, that the problem lies in the mesa package found in [extra], as the opengl version is 1.5. The one in testing is:

Code: Select all

OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RV515
OpenGL version string: 2.1 Mesa 7.9

Using the mesa packages in [testing] eliminated the problem I had. It is funny that opengl 1.5 worked fine in 4.5.0 and 4.5.1 and my compiled mesa-gallium-git packages threw up a bunch of errors. I believe someone reported a bug on this earlier and apparently kwin in 4.5.2 supports gallium. So, just update your mesa packages and xf86-video-ati from testing. Also install testing/mesa-demos if you want glxinfo, glxgears etc. Apparently xbmc won't run unless glxinfo is available.

sweet, it works good now.

thanks a lot!

Same problem here using Kubuntu 10.10 Maverick and KDE 4.5.2 (and KDE 4.5.3).
Using mesa3D I have the same problem showed in the video, flickering screens. Then I install new Mesa with Gallium 3D (r300g driver) and I have the problem described by "ssri", windows become black in Present Windows effect. This last mentioned issue ocurr in Fedora 14 KDE LiveCD too.
I mentioned the problem in this entry:
https://bugs.kde.org/show_bug.cgi?id=253483

and they recommended me blacklist the driver, but does not solve the problem, or I could not do it properly.

Regards.

It is probable the driver blacklisting failed. I would recommend you disable Blur in the meantime.

bcooksley wrote:It is probable the driver blacklisting failed.

Most likely as we do not blacklist the gallium drivers and the key/value pair has to look completely differnt.

bcooksley wrote:I would recommend you disable Blur in the meantime.

Disabling blur does not fix this issue as it's the Lanczos Filter and there is only the blacklist to disable it, sorry.

I would like you to ask to report this problem to freedesktop.org bugtracker. Gallium 3D will soon hit the masses and we should prevent that another driver regression happens.

Ok, I've reported the problem in freedesktop.org bugtracker. I hope I've done well.
https://bugs.freedesktop.org/show_bug.cgi?id=31499

I had not found any previous report about Lanczos filter and Gallium. There were some related to Blur.

If they ask you a question you don't understand, feel free to leave a note here and I'll have a look at it

mgraesslin wrote:If they ask you a question you don't understand, feel free to leave a note here and I'll have a look at it

Ok, it's time. I do not understand what they ask me.

Code: Select all

Tom Stellard says: It looks like some of the KDE devs have identified the failing shader as the Lanczos filter. It would be helpful if you could attach the Lanczos filter GLSL code along with the stderr output from running KWin with RADEON_DEBUG=fp

Thanks.

The GLSL code can be found here:
* http://websvn.kde.org/*checkout*/trunk/ ... ertex.glsl
* http://websvn.kde.org/*checkout*/trunk/ ... gment.glsl

For the debug output I assume they want you to run
RADEON_DEBUG=fp kwin --replace &
from a Konsole.

Thanks mgraesslin. I'll try to do that.

A new question. I have found that forcing the indirect rendering with:

LIBGL_ALWAYS_INDIRECT=1 kwin --replace

I have no more the problem of black screens or empty windows. Only I still have some of the problems mentioned in bugs.kde.org, as corruption in some texts and diagonal lines. Besides using this option I have a better performance in general, everything is more fluid. What does this mean?

Forcing indirect rendering means that the shaders cannot be used. So you are just not hit by the worst driver bugs, though there are different bugs. Indirect rendering used to be the default till 4.5.

Ok, I understand.

Tom Stellard has written a new message in the freedesktop report.