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