KDE 4.6.0 and nvidia drivers

[Duncan]

John Woodhouse posted on Thu, 28 Apr 2011 15:23:35 -0700 as excerpted:

> /strong></div><div><br></div><div>

Please don't post in HTML to the mailing lists.  Many users choose not to 
enable html parsing (or use clients without the option at all) for 
security or other reasons.  You may be able to see some of the resulting 
mess above and below, depending on how well your client cleans up broken 
html.  Since the set of users likely to have the knowledge to answer 
questions and the set of "traditional" users who tend to view HTML 
formatted posts with suspicion intersect rather heavily, it's probably not 
a good idea to risk offending them with posts they consider security risks 
if HTML were to be allowed, but simply an ugly mess since they don't. =:^(

> I was running an older nvdia 7600
> graphics card and it struggled with the desktop effects. The default os
> nv driver doesn't fully exploit this
> card.</div><div><br></div><div>

More HTML junk...

Ehh... the nv driver is deprecated.  nouveau's the replacement, and in 
fact for aging nVidia cards, now generally matches or exceeds the 
servantware nvidia driver's performance, according to recent tests by 
phoronix.  But it does appear that you mention the nouveau driver below...

> About time I upgraded the card so fitted
> a 210 silent. On the nouveau driver it's ok but window
>  movement was somewhat jerky to start off with but has settled down now.
>  Auto timing changes? - KDE decided to disable effects on the 7600
>  within an hour of me using it.</div><div><br></div><div>

More html junk...

>  The glxgear
>  performance with the correct nvidia driver for the 210 is about 4x
>  faster than with nouveau. Full 1680x1060 res gives 200 frames per sec.
>  Nouveau is so slow it's very jerky. On 32bit with the nvidia driver I
>  also saw the slow desktop fade in. Currently with the nouveau driver
>  and the 210 that doesn't happen but windows do go
>  transparent.</div><div><br></div><div>;)

More html junk...

>  I sort of like the effects but to me they mean that os drivers are a no
>  no if they are to be enjoyed.</div><div><br></div><div>

... And even more html junk...

FWIW, I purchased a Radeon (hd4650 FWIW) precisely because AMD /does/ 
cooperate with the community and there are reasonable freedomware drivers.

Of course, I couldn't run the servantware drivers if I wanted, because as 
with most code (including freedomware), there's a disclaimer of liability 
should the code turn out to damage the hardware or whatever.  But how can 
I reasonably be expected to take responsibility for black-box code I can 
neither examine myself, nor have someone I trust examine for me (in the 
case of someone who can't read the sources themselves)?

I'd argue that I cannot reasonably do so.  Thus, I won't waive the 
author's/supplier's responsibilities and take them on myself, and they in 
turn don't give me a license to run the code.  As such, at least here in 
the US, there's a very real legal possibility I do not have the legal 
right to run nearly all servantware code, even should I want to do so.

(And on the basis of that argument, I'd argue that nullifying such damage 
waivers for providers who refuse to open their code, would nicely solve 
the problem.  There are a few providers who *DO* take such liabilities for 
the code they ship -- in airplanes and nuclear reactors and the like -- 
but the cost is *FAR* from trivial to do so.  Thus, invalidating such 
damages waivers on code that the user isn't as equally free to inspect as 
they are expected to agree to such waivers... would solve the problem, by 
forcing black-box suppliers to charge prices to cover the liabilities 
they're not allowed to require users to assume since the users can't see 
what they're assuming.  That would effectively price black-box solutions 
out of the market for all but the most high-priced solutions, leaving the 
consumer software market pretty much 100% freedomware.)


Anyway... before my upgrade to the radeon hd4650, I was running an old 
radeon 9200.  But I refused to turn off effects like window translucency 
that I already knew could work perfectly well on the hardware, because 
they'd worked perfectly well on kde3.  As a result, I learned how to 
select specific effects, turning off others I didn't want/need, and to 
tweak the ones I had on to work acceptably fast.

The big trick is setting animation speed.  This setting is found on the 
general tab under Desktop Effects and defaults to "normal".  By setting it 
to "very fast" or even "instant", effects such as transparency fade-in 
that are otherwise unworkably sloooowwww become far more usable. =:^)  
(Conversely, those with fast graphics and systems may want to set this to 
slow, very slow, or extremely slow, to get the full effect of transitions 
that would otherwise be so rapid they'd hardly see them.  On my new Radeon 
hd4650, I have it set to slow.)

There are a few other similar tricks as well.  One is choosing (and 
configuring) the effects you want individually, on the All Effects tab, 
rather than by group, on the general tab.  In general, effects triggered 
only rarely and only on demand (desktop switching, shutdown, etc) can be 
enabled more liberally than those triggered frequently (window fade-in/
fade-out, especially when switching windows, etc).  Here, I really use 
window translucency, but not shadows, so shadows are disabled, for 
instance.  And the desktop grid is only triggered on demand and can be 
impressive and fun even if it's a bit slow, so as long as it works at all, 
it might be worth enabling.  (Note that desktop cube animation is a 
totalling different effect, designed to be triggered on routine desktop 
switching; I do NOT have it enabled.)

A second is the configuration for window translucency, which allows 
setting the fading duration speed for it alone, separate from the default 
settings on the general tab.  I actually found this setting before the one 
on the general tab (I'm not sure if the one on the general tab even 
existed in kde 4.2.4, when I first switched from 3.5.10) and played around 
with it a bit.  I discovered that on my old hardware, even the lowest 
arrow-selectable 100 ms was WAY too slow -- as if the setting were 
designed for 100 ms total but was actually doing 100 ms per frame, several 
SECONDS total!  But I could type in a much smaller value, and I found 
something on the order of 2-10 ms worked pretty well.  0 ms was no 
transition, just active to inactive in one shot, for instance.  I believe 
that's what the "instant" option on the general tab does too (or default 
here, when the general tab setting is instant), but I liked a /bit/ of 
transition, it just had to be MUCH faster than even the lowest 100 ms 
spinner value, 2-10 ms instead of 100, so 10-50 times faster than even the 
fastest spinner value setting.

A third minor trick is setting the effect and duration of the virtual 
desktop switch, as found in Workspace Behavior, Virtual Desktops, 
Switching tab. 

A fourth minor trick applies not to kwin's effects, which the above 
control, but rather, to plasma's effects, set entirely separately.  This 
is set under Application Appearance, Style, on the Fine Tuning tab.  Set 
the Graphical Effects dropdown to one of the low CPU options.

Another one, should be a relatively minor effect now but due to a bug, it 
had a MAJOR effect in 4.2 and IIRC early 4.3, has to do with activity/
desktop plasmoid/widget placement when window translucency is enabled.  In 
general, on a slow machine, you don't want high-update-frequency widgets 
being redrawn on layers behind the top window.  This is most critical for 
the desktop, which is always behind any windows drawn on top of it.  
Therefore, if you use window transparency at all on a slow-graphics 
machine, only put static or low-frequency update applets like weather and 
the comic-strip plasmoid on the desktop.  Keep high-frequency update 
plasmoids such as system monitors on panels set to auto-hide or always-on-
top, NOT windows-can-cover or windows-go-below.  This way, they'll always 
be the top thing shown and won't affect compositing performance like they 
can if their frequent updates are composited thru several semi-transparent 
windows.  (The bug in early kde4, or more accurately, in early qt4 and the 
way it interacted with early kde4, caused the entire desktop to be 
repainted with each of these updates instead of just the small normally 
rectangular area affected by the update.  That was just too much to be 
workable on slow graphics systems.  Along about kde 4.3.something or 
possibly 4.4.something, IDR exactly, they caught this drag on performance 
and coded things to avoid it.  Later, qt changes made it more difficult to 
trigger in the first place.  Both of these caused the update to trigger 
repaints in only the relatively small affected area, generally that of the 
plasmoid itself, not the entire desktop, so now the effect will be far 
less of a problem than it was back then, but it could still make some 
difference on slower hardware.)

> It's nice to see that 4.6.0 is relatively stable so far.

That it is. =:^)  (Only it's was, for me, as 4.6.2 introduced a 
regression, tho I've temporarily fixed it by replacing the particular 
library in question with the early 4.6.0 version, after which 4.6.2 has 
been fine for me as well.)

This is where I'd normally put the bit about upgrading to the latest kde, 
now 4.6.2, since thru 4.5, each upgrade, both the minor/feature upgrades 
(4.4 to 4.5 for example) and the micro/bugfix upgrades (4.5.4. to 4.5.5 
for example), had enough bug fixes and improved functionality that it was 
worth the upgrade.  However, 4.5 finally reached what I'd call reasonable 
x.0 quality, what /should/ have been 4.0, and other than the fact that 4.6 
drops the hal dependency, it isn't that big of a deal.  Further, counter 
to the previous trend, both the 4.6 micro-updates so far have had notable 
regressions from 4.6.0.  So I've been recommending that folks who are on 
4.5 or previous and are comfortable with hal for the time being, upgrade 
to 4.5.5 and stay there, while those who are already on 4.6 or who really 
need to get rid of the hal dependency that 4.5 and previous had, go with 
4.6.0, and stay there for the time being.  Of course, for most, this will 
be to some extent decided by their distribution's upgrade timing and 
policy, but even so, many can add package repositories with the upgrades 
if they wish, and of course, kde can be compiled from sources as well if 
desired.

So yeah, I'd say stick with 4.6.0 for the time being, seeing as you're 
already on 4.6.0 and find it relatively stable.  Hopefully by 4.6.4 or 
4.6.5, the regressions affecting 4.6.1 and 4.6.2 will be worked out and 
what remains will be an even better 4.6, but that remains to be seen.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.