To alpha_one_x86: the crash you posted is a known issue in ktorrent, as a workaround increase the maximum open file limit, this has nothing to do with oxygen or nvidia or anything else. It is just a matter of to many open files, you can easily get into this situation if you have a torrent with many files in combination with many network connections (they are also counted as open files).
To everybody else who is interested, the workaround I use when rendering is getting slow on nvidia is this: nvidia-settings -a PixmapCache=0 nvidia-settings -a PixmapCache=1 This flushes the pixmap cache, and things are rendered smoothly once more. Joris, On Mon, Jan 3, 2011 at 4:44 PM, Thomas Lübking <thomas.luebk...@gmail.com> wrote: > Am Monday 03 January 2011 schrieb Sebastian Kügler: >> > or help nvidia fix their crappy drivers :) >> >> In the past, aaronp on Freenode was very helpful, maybe ping him? > For the records: i expect this to not be some sort of "stupid bug, fix this > line and we're done" thing. > > The issue has existed all the time. > Nvidia provides 5(!) strategies to allocate pixmaps. (seems they're aware that > there's an issue) > One of them (2, the default) uses a cache mechanism but it _seems_ KDE's > flooding this cache in a row (at startup and then -slowly- over and over again > during runtime) and then things get ugly... err "slow". > Just flushing the cache brings back speed for a while. > > This might be a target conflict, since disabling the cache or setting the > "wrong" strategy slows down XRender xform, which is otherwise at least close > to GL matrix transformations. > > On the other hand, I frankly don't quite understand why the cache isn't > implemented as queue (with a limit on entry numbers, size) or what can be > difficult about allocating a 32bit pixmap (the cacheless modes are pretty slow > and burn shaders and/or VRAM - 24bit seems completely unaffected) given that > the texture fillrate and VRAM speed of the GPUs we're talking about beats the > s...tufff out of the casual intel HW chain, which seems to have no isues with > this at all. > Also the nouveau driver (though not as fast as the PIxmapCache in a clean > state) isn't notably slow on this. > > Thomas > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
