Update: check out this solution.
Amongst users of the proprietary ATI driver (FGLRX), it’s a well known problem that KDE4′s KWin’s desktop effects are unusable due to turtle slow window resizing. Unfortunately, bug reports and forum posts fail to come up with a clear answer as to why this happens, who is responsibility for fixing it, and which parts of the stack need to adapt for the bug. If you’re not already familiar with the problem, observe:
As you can see, the three second delay in window resizing, maximizing, and (perhaps) restoring makes compositing-enabled KWin unusable. Note that the problem still persists when disabling the “show window content while resizing” option.
It’s been particularly difficult to track down the route of this problem and who should be fixing it. From a lengthy discussion on Phoronix’s Forums, ATI’s “Bridgman” user acknowledges the problem but claims “It’s not a driver issue AFAIK, so not sure why we would mention it in the release notes.” He goes on to indicate that the problem was introduced during a hack to ensure KWin compatibility on Intel cards, to work around a glitch with garbage appearing on the screen, and a lengthy debate over the “107_fedora_dont_backfill_bg_none.patch” patch. Somewhere the stack was patched to support Intel cards at the expense of ATI cards, according to ATI’s “Bridgman”.
Over on the KDE bugzilla, we’re met with a curt response from the KWin team: “Driver bug then.” The bug is marked as “RESOLVED” and “UPSTREAM”.
And elsewhere on the Internet, we get a helpless string of “still not fixed” messages, over on the unofficial FGLRX bugzilla, other Phoronix forum posts, and distro forums.
So I ask my readers: who is responsible for this bug and how will it be fixed? If indeed it is neither FGLRX nor KWin and the problem exists in XOrg, why has XOrg been patched to support Intel cards at the expense of ATI cards? Is there anything FGLRX or KWin could be doing to mitigate the problem? Potential workarounds? Users have complained of this problem for over a year now perhaps, but not once has leadership from anywhere offered a compelling explanation or plan for the future. What to do?
Leave comments. The current discussion seems to be fruitful.
Hey, how did you add these cool “speech bubbles” to the video?
The xorg-server is responsible for this behaviour. The xserver had an “option” or something, that the fglrx-driver used (and still is using), but the newer xserver don’t have this “option”, or what it is.
In Ubuntu, Fedora and Arch Linux, there are patched xservers like this one: http://aur.archlinux.org/packages.php?ID=26687
Resizes smoothly enough here with Radeon 4850 using catalyst 9.7. I’m personally more worried of the slowing down when using other windecos than oxygen/ozone/aurorae.
@bliblibli
You have compositing enabled?
Well, IMO it’s now ATI’s problem. Sure, the hack to fix Intel issues sucks from their perspective, but if the Intel cards aren’t showing the slowdown then it’s pretty obvious that the problem is that it’s forcing ATI cards down a slow path in their driver. Complaining about the hack causing them problems is OK for a month or two while they work on accelerating the new path is fine by me, but by this point it should have been solved. And from what I can tell, they aren’t even trying to fix it, but rather still trying to get intel hack removed.
So to get some facts. First of all: I’m working on the KWin OpenGL compositing part for 1.5 years now, so I think I know a little bit about it
I work with an NVIDIA card and AFAIK all other KWin devs as well. Nevertheless I bought an ATI card for testing (which I hardly never use to be honest).
I do not know of any hacks added to KWin because of Intel. If there are some, please point me to the code.
About the Fedora patch: we never added anything to KWin to work around the backflip patch. That’s a problem Fedora and Ubuntu introduced and we don’t fix problems in distributions. Ubuntu dropped the patch in 9.04 and I have no idea about Fedora.
So with that said: let’s look at the technology. When using compositing we use an GLX extension called texture from pixmap. The painting of a window is redirected into a pixmap and an OpenGL texture is created from that pixmap. When resizing, the size changes and a new pixmap has to be created. The application has to repaint it’s content (into the pixmap) and the compositing manager has to repaint the area on the framebuffer. From my experience so far the most important part in that process is the texture from pixmap. That is done by the driver.
AFAIK the first drivers which supported this technique was the NVIDIA, the last driver to support it was the ATI. I don’t want to blame anyone but we can ask ourselve “how good is the technique implemented in the driver which supported it last?” Oh and when speaking about ATI, why doesn’t the ATI driver support direct rendering when using compositing? Why can’t we use shaders? So I hope that explains why we set those bugs to RESOLVED UPSTREAM. We see it working in all other drivers and it fails with one. (Of course resizing is slow with all drivers, but that’s caused by the technique and we offer an option to disable the “slow” resizing)
Oh one thing I want to mention. Qt added support for XSync in Qt 4.6. I have not tested it yet, but it might improve the situation. Have a look at this blog post: http://labs.trolltech.com/blogs/2009/06/10/smooth-and-solid-resizing-on-x11/
It would help if the source code was available, so people could actually see where the problem was
Just want to say that I’m running KDE 4.2 on Ubuntu 9.04 here and don’t see the slowdowns that are in the video when compositing is enabled. There is a delay of a few milliseconds, but I can live with that(I’d prefer a smooth experience of course)
My card is an ATI Radeon 3200HD (on a laptop)
I am not that knowledgeable on this stuff but it seems to be the driver’s fault, unless KWin uses different code for different drivers.
so I just clicked through the Phoronix thread and read each comment written by an AMD member. I please invite everybody to read comment #50 (http://www.phoronix.com/forums/showpost.php?p=61000&postcount=50) and to think about whose to blame.
Have an ATI card on my Dell Studio laptop … proprietary drivers don’t work at all (black screen) on all Ubuntu post 9.04
@Matt
Maybe? I’m mostly wondering what we can do to fix this… If something can be done on KWin’s side or XOrg’s side. And what specifically does FGLRX need to do to be better?
@Martin
Thanks for the details. It’s helpful to know what goes on with the KWin development. Bridgman writes:
“The optimization in question (which was *removed* in 9.04, the patch puts it *back*, is desribed as: – 107_fedora_dont_backfill_bg_none.patch
Disable backfilling of windows created with bg=none, which
otherwise would force a framebuffer readback. Note that this is a “go fast” patch; later discussion talks about a ‘go slow” patch which backs out the optimization. I believe the optimization became an issue when KDE4 hit, since it resulted in momentary garbage appearing on the screen with certain hardware (Intel IGPs mostly, but it was also reported occasionally on NVidia and ATI/AMD hardware). Removing the optimization made the “flashing garbage” problem go away, and did not cause obvious performance problems on Intel IGP hardware since IGP parts don’t have dedicated vram for the framebuffer (so readbacks are fast).”
So if this is the culprit, then the problem is that this patch *was* dropped in 9.04. According to Bridgman, it’s required for good performance with FGLRX.
Does the issue have something to do with EXA?
You keep pointing your finger at “ATI is evil and doesn’t care. Sorry nothing can be done to help you then.” But if you had an ATI card, I bet you’d be a lot more interested in solving this, in determining where in the stack the problem was, and how to work around it…
You blame the texture_from_pixmap implementation. The thing is that the other desktop effects work fine; it’s just resizing/restoring that has the huge lag. What accounts for this?
I tried the XSync sample app attached to the QTLabs post you linked and it didn’t have any effect on the problem.
Is there anything we can do to speed this up? All of those shiny desktop effects are useless to FGLRX users because of the horribly slow resizing. Any possible KWin special casing possibilities?
@sandsmark
Yup.
@Agony
You running FGLRX?
@laleshii
Head on over to the ubuntu forums. Barking up the wrong tree here.
Yes, running the FGLRX driver that ships with Ubuntu 9.04
I’m really sure that this is a FGLRX problem, not Kwin’s problem. Since resizing works greatly with all the other drivers EXCEPT fglrx, that is fglrx’s problem.
ATI’s proprietary driver is I’d say a driver that cannot be used properly on a production system (desktop, workstation). It doesn’t support sufficient 2D acceleration, 3D acceleration through fglrx makes the system unrensponsive (for example: try, with effects enabled, to… press the Kmenu button on KDE4. There will be a 1-2 seconds delay.
That’s unacceptable.
I think the mr. Bridgman shouldn’t say such things in order to protect AMD, since it’s know to everybody that fglrx is one of the worst piece of software out there.
PS. I’ll surely try to forget the fact that Fglrx barely supports Linux kernel 2.6.30 and Xorg server 1.6.x
@ Article (1):
“Over on the KDE bugzilla, we’re met with a curt response from the KWin team: “Driver bug then.” The bug is marked as “RESOLVED” and “UPSTREAM”.”
I marked it as upstream because of this comment:
“Because of a broken plasma I’m using Xfce right now and it has the same window
resizing problem.”
@ Article (2):
“He goes on to indicate that the problem was introduced during a hack to ensure KWin compatibility on Intel cards”
We have no driver-specific hacks in KWin code. The “Intel hack” was applied by distributions, not us. It’s not even a hack either, it was to make X no longer follow specifications in regard to pixmap allocation. With it applied KWin would receive a pixmap filled with garbage but told it contained initialised window data, thus it resulted with KWin displaying garbage to the screen. The problem did not occur with Compiz because users were only testing with GTK+ applications that support XSync, Qt didn’t support this until the unreleased 4.6 version and because of the lack of Qt support KWin has yet to be upgraded to fully support this as well.
Distributions applied the hack because it prevented X from reading data back from the graphics card (Why it needs to read data to be able to initialise it I have no idea…), a technique known to be slow. If an application used XSync it would prevent a compatible window manager from displaying the garbage until it had finished painting. They believed that since there was a workaround in GNOME that worked they were allowed to break specifications (And thus break Qt/KDE).
@ Jason:
“You blame the texture_from_pixmap implementation. The thing is that the other desktop effects work fine; it’s just resizing/restoring that has the huge lag. What accounts for this?”
Whenever a window is created, restored or resized the graphics driver is required to allocate a new texture/pixmap for the window–all other events do not require this allocation. Unless someone can show me a performance profile that shows that the delay is not during this BLOCKING call then I’ll assume this is where the slow down is.
I am aware of a separate KWin slow resize issue (That I would like to fix for 4.4 and relates to XSync) but as that one occurs even when compositing is disabled it has nothing to do with the problem you have showed here.
>>We have no driver-specific hacks in KWin code. The “Intel hack” was applied by distributions, not us. It’s not even a hack either, it was to make X no longer follow specifications in regard to pixmap allocation.
I think we’re saying the same thing here. The change that resulted in the performance problem was in Xorg, not KDE.
>>The problem did not occur with Compiz because users were only testing with GTK+ applications that support XSync, Qt didn’t support this until the unreleased 4.6 version and because of the lack of Qt support KWin has yet to be upgraded to fully support this as well.
I suspect this may have been the missing bit of information. From what I can see the Xorg developers felt the issue was a difference in KWin vs Compiz implementation (and thus able to be changed in KWin), not a difference in the underlying toolkits which is *not* so easy to change quickly.
>>Distributions applied the hack because it prevented X from reading data back from the graphics card (Why it needs to read data to be able to initialise it I have no idea…), a technique known to be slow.
Yeah, I think the readback is the part nobody understands. Some card/driver combinations do it faster than others, but there still seems to be debate about whether readback is the correct behavior either. I’m hoping we can get some agreement on the underlying issue before XDC so that if nothing else we can get the question beaten into submission there.
I should also mention that all occurrences of “XSync” on this page should really be references to “_NET_WM_SYNC_REQUEST”. XSync is something different. >_<
>>Somewhere the stack was patched to support buggy Intel cards at the expense of well-behaving ATI cards, according to ATI’s “Bridgman”.
Just to be clear, this is *not* what I said. All I said was that the problem appeared with KDE4 and Intel GPUs, and a solution presented itself in the form of backing out the 107 patch.
If you read through the KDE bug ticket (http://bugs.kde.org/show_bug.cgi?id=165011#c14) you see performance complaints on intel, nvidia and ATI/AMD hardware. The date was July 2008 on Debian, which is a useful clue – I hadn’t heard of anyone pulling the 107 patch back then.
Anyways, just to be *really freakin’ clear* here, Jason has paraphrased what I said with the best of intentions, but the end result is different from what I said and much more provocative. I did *not* say that the Intel drivers were buggy, and I did *not* say that this was KDE’s fault. What I *did* say was that the “garbage on screen” problem seems to have first appeared with KDE4 and Intel hardware, and that the response to *that* problem seems to have been pulling the 107 patch, which resulted in a performance problem. Most of the bug tickets I have seen (including the KDE ticket) mention performance problems on all vendors hardware, not just one.
I don’t know why the performance problem was reported on Debian back in mid-2008. It seems that the KDE ticket was closed as “driver problem” after a user reported similar performance issues with KDE on xfce (post 13), but that doesn’t jive with the earlier posts in the same ticket where the performance problem was reported on NVidia, Intel and ATI/AMD hardware.
Peter, did you read my posts or are you just responding to Jason’s description of what I said ? If the latter, please read my posts if you have time. I think you’ll find them much more palatable.
Right now the KDE and Xorg developers seem to have different views of where the real problem is, and I don’t know what to do about all the reports of similar performance problems appearing on other vendors hardware as well. My first thought was that this might be an EXA vs XAA thing, but the user reports don’t seem to support that so far.
Martin suggested that slow handling of GLX_EXT_Texture_From_Pixmap on fglrx might be the issue, but that conflicts with comments from other Xorg developers and doesn’t explain users of other hardware also reporting the performance problems.
We can always stuff a workaround in our driver but as long as people are reporting performance problems across all hardware vendors that doesn’t seem like the right thing to do. This is going to get solved by having everyone agree on what the root problem is, and where it needs to be fixed, and that won’t happen while everyone is pointing fingers. I’m sure Jason’s intentions were good but before anyone reads his summary and gets mad please read the original comments first.
Thanks,
JB
P.S. Martin, AFAIK we have supported direct rendering with composite for almost two years now, and shaders for much longer. I’m sure there are specific issues behind your comments; can you point me to some more detail, maybe a bug ticket on ati.cchtml.com ?
Yes you supported direct rendering, but since Catalyst 8.5 it is broken again. We have a bug report for it: https://bugs.kde.org/show_bug.cgi?id=173556
The bug mentions other vendors as well, nevertheless the problem AFAIK only occurs reproducable with ATI cards. There is a hack to force direct rendering by using an environment variable. The results using that varies from crashing X to unusable system with my ATI card. Last time I tested, I used a Kubuntu 9.04 with it’s default drivers.
Thanks, Martin. I had seen that ticket, but posts #21, 22, 25 and 26 report the same -problem happening on Intel and NVid ia hardware as well. The bug report kind of hints that your code might be getting different response between GL and GLX re: whether a specific extension exists, but it wasn’t clear what extension your code was looking for.
I believe Martin was referring to comments #24, #26 and #27. As for what extension KWin tests for they are GL_ARB_shader_objects, GL_ARB_shading_language_100 and GL_ARB_fragment_shader and does so by parsing the glGetString(GL_EXTENSIONS) output after the required context has been initialised.
@bridgman
Sorry for misrepresenting you. I clarified things a bit. So in your opinion, where does the problem occur? XOrg? KWin? Or do you think that the resizing bug is due to a shortcoming in FGLRX?
@lucas
Thanks a lot for the explanation of the intel patch. That clarifies things greatly. So do you suppose the problem is then with FGLRX or some place else? The (perhaps inaccurate) vibe I get from Bridgman is that driver specific code in KWin might be necessary.
>>The (perhaps inaccurate) vibe I get from Bridgman is that driver specific code in KWin might be necessary.
Last comment;
Just to be clear here, I am *not* suggesting that driver-specific code in KWin might be necessary. I’m saying that there seems to be lack of agreement on what the correct behaviour is, and a lot of pressure for us to implement that behaviour
What I mentioned above is pretty much the extent of my knowledge on the issue as I’ve only worked on low-level compositing code for a couple of weeks total since I joined the KWin team a little over a year ago.
I actually think there are multiple resizing bugs currently present in KWin: One for multi-second delays on ATI/AMD hardware, one for sub-300ms delays on all other cards and one relating to EWMH syncing that occurs even when compositing is disabled. This is potentially why there are so many contradicting comments in the relating bug reports.
I don’t know where the problem is yet. At the time I started posting there were reports of performance problems on hardware from all the major vendors, which either meant that all the vendors had similar driver bugs or that the problem was not in the driver.
What I suspect is happening here is that KDE is making legitimate use of some Xorg functionality which in turn results in a readback that probably should not be required. Other compositors had run into similar problems in the past, and Xorg had been patched to avoid the readback. I don’t think the question of “which behaviour is correct” was ever resolved; the original patch went in because the readback seemed wrong to the X developers.
The current situation is that the readback is happening again (which does not happen in normal operation), and I suspect the performance varies from card to card and driver to driver depending on things like how the video memory is mapped (cached/uncached etc.). The question is whether the readback path is the right solution; all of the early discussion seemed to indicate that it was not the right answer either but discussion seemed to stop once the idea of removing the 107 patch appeared.
At first glance it seems that readback is not a good solution unless there is a standard acceleration hook for it – my first thought was maybe EXA provided the hook and XAA did not, but that doesn’t seem to be the case either. I guess what I’m saying is that we need to get agreement on what the right behaviour is – readback via a specified acceleration hook, or handing over an uninitialized pixmap when a background is not specified, or something that hasn’t been discussed yet like zeroing out the pixmap – and once that agreement is there it should be pretty easy to implement the right solution.
> depending on things like how the video memory is mapped (cached/uncached etc.)
Being the odd guy here with FGLRX performing nicely(meaning only sub 300ms delays on resize) I thought I should add that my card only has 64MB dedicated VRam, the rest is shared.
I hope this helps.
“I actually think there are multiple resizing bugs currently present in KWin: One for multi-second delays on ATI/AMD hardware, one for sub-300ms delays on all other cards and one relating to EWMH syncing that occurs even when compositing is disabled. This is potentially why there are so many contradicting comments in the relating bug reports.”
This comment is right on point. The multi-second delays are specific to fglrx. They do not appear on Intel, Nvidia or the OSS Ati drivers. However, they are appear on both KWin and Compiz, as long as the backfill patch is not applied to Xorg. Applying the patch fixes the problem at the cost of momentary garbage. Turning compositing off will also fix the issue.
What does this tell us? The most likely explanation is that we are hitting a slow code path that involves GPU readbacks, which was avoided by the backfill patch. This slow path appears when using Textured2D (fglrx-specific) and composition. The effect is much less pronounced on EXA or Nvidia’s acceleration architecture. Shared-memory GPUs are also expected to be less affected (Agony’s comment confirms this).
Where does this leave us? My suggestion would be a discussion during XDC by all involved developers. At this point, it’s not clear what the correct solution is:
1. Is the readback necessary? Can the protocol be changed to not require it? (Xorg update)
2. If it *is* necessary, can fglrx be modified to accelerate this code path? (fglrx update)
3. If none of those solutions works, can this code path be avoided by the compositing managers?
One final thing: GPU readbacks, especially blocking readbacks, are one of the slowest operations on modern PCs (right after disk IO). Reducing those will have a positive effect across all hardware that *could* result in lower power consumption.
This is surely not a FGLRX only problem. I experience painfully slow resizing with the free radeon driver as well. A single resize takes about 4 seconds here.
The system is Athlon64 3,2GHz, Radeon X800 (chip 420), Ubuntu 9.04 Jaunty (Xorg 1.6.0, Radeon driver 6.12.2).
I don’t think this is a performance issue, as it is faster even on a slower machine with a slower Nvidia card and the buggy Nvidia legacy driver…
Me too! I’m running the free ATI drivers on my Lenovo T60 with a Radeon Mobility X1400 caard in it. Ever since upgrading to KDE4.3 pre release I’ve had this problem. Running Kubuntu 9.04
I don’t know if this could help:
With the fglrx-driver and compositing _disabled_ it takes about 5 seconds between pressing the “shutdown-button” in the k-menu and the apperance of the “countdown-dialog”.
With the free drivers the countdown-dialog appears in the moment the menu-entry is pressed.
Just to note as others have said too that I’ve got the same on Debian Lenny (+ kde from sid) BUT on a nVidia 7600 with propietary drivers.
I’ve tried various driver versions versions, including the last one released just days ago. I’ve seen this both with different versions of kde 4.2 and also on 4.3 (installed just today)
Other than the resizing thing, kde 4.3 has seems to have brought massive performance improvements. No measurements, but it feels much snapier.
It’s strange that people who use KDE talk about it as about a problem. I have managed fglrx to work perfectly only in KDE and KWin. In the “Configure – KDE Control Module” window, in “Desktop Effects” tab, I have chosen “Always” near title “Keep window thumbnails”, and everything became quick and comfortable. I have solved the problem, so I am sure that it is NOT the driver problem.
But it is still a problem, because I haven’t find how to do the same in Gnome or Xfce.
(Sorry for bad English.)
Thank to greatperson I too have managed to overcome the slow window resizing problem in KDE. Now it works great. But there still exists the delay in the K-menu appearance after clicking of the K. Anyway, it doesn’t disturb me much, so thank you greatperson for the trick.
Hi, I have been pissed off by this problem a long time and assumed it was ATI’s fault. Tonight I made one last effort before ordering a Nvidia graphics card. And I was successful.
I am running catalyst 9.8 using a Radeon 3850 and have had this re-size/maximize problem as long as long as I have used KDE4. To solve the problem I needed to modify a file in xorg-server. in the code directory it is called ./composite/compalloc.c. Here I commented out most of a function called compNewPixmap. Everything below these lines:
pPixmap->screen_x = x;
pPixmap->screen_y = y;
all the way down to (but not including) the last line:
return pPixmap;
After this I am running KDE4 with all desktop effects that I want and without any lag in resizing/maximizing.
I am running Gentoo, so I just updated the xorg-server source package file and put it back into the source repository, rebuilt the manifest and emerged it again. Voila!
Hi,
I alsa had the resize/lag problem and tested your workaround.
It works for me too.
I am running a Gentoo, with an xserver-1.5.3, KDE 4.3 and Catalyst 9.8 Driver on a Radeon HD 4670.
[...] и пр. можно почитать захватывающий, со всеми ссылками тред про сей баг (на буржуйском), где товарищи (в том числе и [...]
[...] a much heated discussion about how to fix the horrible resizing and performance bug with FGLRX and KDE4, no one knew where [...]
Hi there,
I can confirm both the problem and that the patch works.
But I would like to mention a different problem that was not discussed here. Besides the ‘resize’ problem, there is another one when ‘moving’ a window.
When starting a drag, the window moves 1mm, then stops, and it takes another 5-10 SECONDS before it starts moving again. Surprisingly, after that, I can move the window very smooth. Anyway, it’s very annoying (soooooo slow).
This happends both before/after the recommended patch for compalloc.c
I use an ati x1400, xorg-server 15.3-r6, kde 4.3.1, kernel 2.6.30 with radeon driver
thanks
Chris
[...] is of course no working composition with KDE because you cannot resize windows really (see this blog entry). I don’t care whether the bug lives in X.org or in ATI; if it would be in Xorg then ATI [...]
Hello guys!
As i’m newbie here, i just want to say hello.
By the way – bb code seems to feat bad?
cheers,
______________
cresiarp
[url=http://forums.acdjapan.com/index.php?showuser=3659]cheap price soma Otago[/url]
http://forums.acdjapan.com/index.php?showuser=3659
I should mention that one of our devs (Felix) has provided an Xorg patch which eliminates the readback (thus resolving the performance issue on fglrx and other drivers) and replaces it with a clear operation (thus resolving the “garbage on screen” issue seen with Intel hardware). See comment #228 at :
https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/351186?comments=all
@bridgman
Thanks! I’ll test this out immediately and let you know how it goes.
Any chance of this being included upstream?
Also, and progress in investigating why there’s a readback on backfill only on fglrx but not on any other driver?
I don’t post often. Or without cause.
BUT, despite our cultural bias to accept all or any contribution,
This ticked me off to an Enormous extent.
“Oh and when speaking about ATI, why doesn’t the ATI driver support direct rendering when using compositing? Why can’t we use shaders? So I hope that explains why we set those bugs to RESOLVED UPSTREAM. We see it working in all other drivers and it fails with one. (Of course resizing is slow with all drivers, but that’s caused by the technique and we offer an option to disable the “slow” resizing)”
I ask. Do we need an obvious Nvidia Fanboie going out of his way to make ignorant comments about situations he knows naught a damn about, in a position to affect cross platform compatibility. There are those who DO lnow the details of why, if, or when a compatible direct and shader lib wil be available. those issues are being worked in good faith, by many. The last thing these interlocking projects need, are contributors getting pouty or vengeful becuse the seesaw of bugs/features between chipsets, spoils thier pretty code.
His post was enlightening only in that it exposed some of the bruised, sulky thinking that let a global project wave a finger at a few million users.
I, and my teams, have a damn good reason to use ATI/AMD whenever atall possible.
If you’re interested, ask. 99% of my stuff runs SLES on contract. Some of my guys need to run in the lead pack. I don’t need 1 bruised ego to brick my infrastructure without minimal diligence.
KDE’s history bears constant witness to how maturity, and dedication can win.
This issue, and a few recent others like it, demonstrate how leadership sometimes fails to control adolescent behavior.
This thread, has sown us at least one person that needs to grow up.
[...] by a long shot, so I’ll be using FGLRX too. Shucks. At least ATI’s own John Bridgman has pointed us to a solution for the KWin resizing compositing [...]
Hi,
I have (since a few weeks) a notebook with an ATI card in it and use KDE (just now 4.4 beta 2 on kubuntu 9.10) and i have horrible resizing performance! It takes between 2 or 3 seconds till a resize is completed. Now i did a tiny test. (open the system monitor and see which progress is sucking up cpu while resizing. that one is: XOrg! not kwin! So, my initial thought is that XOrg is the one playing mean here.
And since i will be using this notebook (with the same setup) for a long while i will hunt this issue down to the actual lines of code that cause this. I will go as deep as possible. I just want this fixed and since noone seems to have traced this down to the actual code lines i will do so.
Note: i also have the same setup on a nvidia machine and that runs just smooth! So assuming the issue is in XOrg it either is a “special” code path for != nvidia or for == ati or the issue is within the ati driver. I will post a comment here when i know more.
About this bug, I have a Radeon Mobility HD 4850, and I have this problem.
I’m not using KDE, but windowmaker.
No Compositing effects, but AIGLX is used.
3D works really fine, videos with GL driver too.
But resizing and moving windows is a pain.
What I can add is that things changed with kernel 2.6.32 for me. I tried many things : different FGLRX versions, and kernel versions. Up to 2.6.31 everything is fine. From 2.6.32 it’s not.
With 9.12 fglrx version, it simply wouldn’t compile for 2.6.32. There was a patch somewhere which allowed it to work, the problem appeared there for me for the first time. I switched back to kernel 2.6.31.
Now fglrx 10.1 is there and compiles for 2.6.32, but the problem is the same !
I didn’t change my Xorg version, it is X.org server 1.6.3.
I’ve tried different options in the linux kernel, and many versions from 2.6.32-2 to 2.6.33rc6, many things in X.org conf, it’s always painfully slow…
I haven’t tried older ATI drivers.
Maybe it has something to do with the kernel ? Something which changed there ?
Yth.
NiceSite
[...] internet natrafiłem na dwa wpisy na blogu Geek Ideas. Autor prosi czytelników o pomoc w znalezieniu powodu takiego stanu [...]
.U2kjmsanDfM
Slow Window Resizing with KWin Compositing on FGLRX | Nerdling Sapple