Bogus Zaba posted on Sun, 16 Sep 2012 17:21:15 +0100 as excerpted:
> On 09/15/2012 03:40 PM, Duncan wrote:
>> Bogus Zaba posted on Fri, 14 Sep 2012 19:59:15 +0100 as excerpted:
>>
>>> I am not desperate to have all possible eye-candy operating, but I
>>> know that my system is capable of reasonable performance with regard
>>> to stuff like box-switching etc because it has worked before.
FWIW, I know the feeling. I remember having a similar feeling a few
years ago when I first upgraded to the then still incredibly buggy "alpha
grade" (despite kde claims to the contrary) kde 4.2. While I've since
upgraded hardware, my workflow had come to depend on semi-transparent
windows in the kde 3.5 era, so I knew there was absolutely no valid
reason that kde4 couldn't handle at least window transparency.
I was correct, too. IDR the exact version now, but IIRC it was near
4.3.2, when one of those serious bugs was fixed, and kde4 suddenly became
*MUCH* more usable, speed-wise, tho by that point I had configured around
the worst of the problem.
The point is, when you know what a system /can/ do, it's difficult to
take people saying it can't, that you need better hardware, when you know
it DID work and still does with the old version, so the fact that it's
not doing so now is evidence of a serious software bug.
>>> The system has an nvidia GeForce 7300 card and I am using the nvidia
>>> (proprietary) driver. The KDE is 4.5.5 under Slackware 13.37 which is
>>> the best I can run under Slack 13.37 without making some other
>>> significant system changes.
>>>
>>> Recently KDE [is forcing jerky/slow] XRender. If I try and switch to
>>> OpenGL I get "Failed to activate[" and reversion to XRender.
>>> Reinstalling the nVidia driver doesn't help, and its opengl checks
>>> out.]
>> [Did you recently upgrade anything? Upgrading one component to newer
>> while keeping the system in general older might do this.]
> Kernel is 2.6.37.6 - as supplied with Slackware 13.37.
> xorg-server seems to be 1.9.5 as supplied with Slackware 13.37.
> The nvidia driver is 295.33 as supplied by the semi-official
> "Slackbuilds.org" repository.
>
> So none of the above are very recent upgrades - all about 1 year old.
OK. The list of immediate suspects seems to check out. Nothing
interesting there.
> As I was getting this information together I remembered that there was a
> published reliable way of upgrading to KDE 4.6.5 from 4.5.5 without
> making major changes to the system, so I went ahead and upgraded. All
> seems to have worked well - KDE reports that it is now at 4.6.5, but
> same message when I try and switch from Xrender to OpenGL for desktop
> effects.
No luck there. Frustrating!
>> Just to confirm. There's an app called glxgears. [Can you]
>> see the gears still? If so, you have at least /minimal/ glx
> Check - this works fine and glxgears reports about 1700 fps.
That was a long shot anyway, but it's still useful confirmation.
>> IDR if kde 4.5 had it or if it was added later, but if you have a
>> checkbox for opengl shaders, try unchecking that.
> Here are the options on this tab (in KDE 4.6.5):
> * Disable functionality tests (right under the compositing type
> drop-down list. This is checked.
FWIW, while I remember that option now that you mention it, it's gone in
newer versions (from 4.7 I think, it had a number of DRAMATIC kwin fixes/
improvements). There were some specific bugs that it was there to allow
working around, but they've been addressed now. I believe I remember
reading a kwin dev's blog entry on it around that time, but unfortunately
the details are fuzzy now. But after addressing the problems it was
there to provide a workaround for, the option was either useless or
causing more problems than it solved, so it was removed.
FWIW, the new method finally defaults to a much saner effects off until
enabled policy, as well as testing the functionality for each individual
effect and disabling just that (with a notification on which specific
effects couldn't be enabled) when effects are switched on. There's an
option to enable effects automatically on login (on the left/first tab
where it's more visible), but it's OFF by default, and there's a warning/
confirmation dialog asking if you're sure you want to enable them by
default, since that could keep you from getting into kde if something
goes wrong, when you do enable it.
In general, then, things are MUCH more robust now. I really do wish
they'd had it working this way by the time they called kde4 ready for
normal use with 4.2, as it would have dramatically improved the early
kde4 user experience, but too late for that now. At least it works the
way it should have all along, now. =:^)
> * Keep window thumbnails (This is set to "never")
That option's still there (in 4.9). I've actually tried it with all
three settings, but don't see much difference. The "breaks
minimalization" warning doesn't seem to be entirely true, however.
Minimalization still works, but I think it does break thumbnailing from
the tasklist plasmoid, which I don't happen to use anyway, so I don't see
it.
> * Scale method (Set to "crisp" rather than "smooth")
That's still there. On a reasonable GPU smooth should be fine but crisp
is definitely the best for troubleshooting or if you're having speed
issues.
As I'm running a radeon "turks" hd6770 now (freedomware drivers, the
northern islands series of which turks is a part are the latest fully
supported hardware, southern islands are newer, but WAY more expensive
and not as well supported yet, with the freedomware driver anyway), I
really don't notice much of a difference in either speed or quality
regardless of the setting (tho I have it set to accurate, purely because
I can), but crisp is the best choice if you're seeing speed problems,
particularly since it /doesn't/ seem to dramatically affect quality.
FWIW, one of the "DRAMATIC improvements" I mentioned is much improved
help. For this one there's now a tooltip that has an explanation for
each option. Crisp uses GL_NEAREST and is said to be fast on all GPUs
but "bricky". Smooth uses GL_LINEAR and is said to be fast on most GPUs
but a bit "blurry". Accurate requires Lanczos filter functionality and
shader support. There's a warning that it could be slow or even trigger
crashes on weaker GPUs, and recommends falling back to Smooth should that
happen.
> * OpenGL mode (Set to "Fallback" rather than "Texture from pixmap" or
> "shared memory"
THAT option's missing, now, tho again I remember it. It may be that the
Use Opengl 2 Shaders option I mentioned replaced it. Or it may be that
it's not needed, now that they auto-detect individual functionality.
I do know that at least Radeon hardware of r600+ chips or newer (nearly
all the hdXXXX series, the xXXX series were r3xx-r5xx and the numbers
only models were the original radeon r1xx thru r2xx) works very well with
texture-from-pixmap and believe that's what I had set with my rv730/
hd4650. In fact, texture-from-pixmap works SO well on radeon that it's
what they use to implement the old overlay video mode on newer GPUs.
I also know that my radeon hd4650 (rv730) was broken with OpenGL 2
shading, once that option was available. That actually locked me out of
kde for awhile, as I have the enable effects at startup option set. I
had to rename the kwinrc file to get back in, then experiment a bit to
figure out what option was the problem.
But when that system (which was still AGP) died and I upgraded to a PCIE
system, of course I had to upgrade graphics cards accordingly, and my
newer radeon hd6770 (turks, they did away with the rXXX chip numbering,
northern islands series) works *VERY* well with shaders, etc.
But I've little idea whether/how any of that maps to nVidia, and indeed,
no idea how recent/old your gforce 7300 might be.
> * Enable direct rendering (Checked)
This option's gone, now, tho AFAIK it can still be controlled via
environmental variable. I really should try experimenting with that
again, since the last time I did was on the old system.
(This is what I have in my .bashrc regarding the variable. As you can
see, it's commented ATM, so I should have direct rendering.)
# KDE4 kwin OpenGL composite
# http://dot.kde.org/1195074194/1195113392/1195122064/
#export LIBGL_ALWAYS_INDIRECT=1
When the option was there, I tried experimenting both with it and with
the environmental variable. It didn't seem to make a lot of difference,
but one way, one effect broke while another worked, the other way,
reversed. I really wanted both effects, but couldn't have both. (The
effects were opengl-accelerated color-invert, and snow. But the snow
effect disappeared from the list some versions ago... you probably don't
even have it in 4.6, so...)
> * Use vsync (also checked)
This option's still there. At least older radeon drivers used to enable
vsync by default, however, limiting for instance glxgears to the 60 Hz
refresh rate of my monitor. It was possible to disable vsync and get
full speed glxgears, but I had to do it via X/DRM config, the option here
had little effect. Of course tying to refresh rate is arguably a good
idea since you can't see what the monitor hasn't had time to draw in any
case, but it did put a kink in my ability to compare framerates against
others I saw published.
On a current software stack, however, while the option's still documented
for the driver, if it still does anything at all, it's not affecting
glxgears anyway, as it's reporting full rates, now, and did so on my old
system as well, so it's not hardware related. (FWIW on my current hd6770
hardware with native drivers, glxgears reports 2000-3500-ish FPS at the
default window size. That's with effects enabled including window
transparency (tho if I use the zoom effect to zoom in, framerates drop
DRAMATICALLY, to only 113-166 or so, I wouldn't have expected THAT big a
drop, particularly when effects toggle in general and transparency,
which /used/ to have a big effect, has approximately zero effect now,
but...). Even at the full size spread across two monitors stacked for
1920x2160, I still get 60-80 fps, above the 60 Hz monitor refresh-rate.
But glxgears is pretty basic glx so hasn't been a good benchmark for
years, tho it does still serve its purpose as a quick basic glx-working-
at-all-or-not test, which is why I asked about whether it worked at all,
not about its reported framerates, above.)
> I have played randomly with many of these but no combination that I have
> tried has fixed the won't-switch-to-OpenGL problem.
My experience with being locked out of kde due to the shaders option was
why I asked about it. But I guess you don't have it to check on 4.5/4.6,
and the all-or-nothing opengl check it used is unfortunately locking you
out of opengl.
But writing all the above made me think of another troubleshooting
suggestion. =:^)
On the middle tab, try disabling ALL INDIVIDUAL effects (even the ones
you don't want to do without, permanently, and that you believe should
work). Hit apply.
Now on the advanced tab see if with all /individual/ effects disabled,
you can successfully switch to opengl.
Hopefully that works. If so, you can try enabling individual effects one
at a time and see what's killing it. But, be prepared to crash and to
edit/rename/delete kwinrc to get back into kde, if necessary, because the
one you just tried isn't working, and with kwin's all-or-nothing approach
back then, there IS a fair chance that when you enable that one, you'll
trigger a crash and won't be able to get back into kde until that bit of
the config is removed.
> We are expecting a new Slackware version any day now which will ship
> with KDE 4.8. I am inclined to wait now until this is released after
> which I will upgrade or fresh-install. Could well be that the upgrade
> will cure the problem. If not that will be the time to devote more time
> and effort to it.
Yes. I've seen the slackware betas mentioned on the various FLOSS sites
I follow. In fact, I thought the new version was actually out already,
but it must have been just the betas I was reading about.
It's sad to be leaving the "leet" 13.37 behind, but it had to happen
eventually, I guess. 13.37 was easy to remember, tho! =:^)
> Thanks for all your suggestions.
Based on what I know, I'm quite optimistic about the "individual effects"
idea above, so please do try it and report back. Of course if the new
slack comes out first, by all means try it as it basically does the same
thing but automatically, but the manual method's definitely worth a shot
if the new version doesn't come out first, because I really DO think
there's a good chance it'll work!
--
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.
