Nikos Chantziaras posted on Wed, 21 Apr 2010 03:36:31 +0300 as excerpted:
> On 04/20/2010 03:28 PM, Duncan wrote:
>> Nikos Chantziaras posted:
>>>> On 2010-04-20 11:02, Nikos Chantziaras wrote:
>>>>> [garbage/artifacts when scrolling Konqueror here]:
>>>>> http://www.nongnu.org/mingw-cross-env
>>>>>
>>>>> KDE 4.4.2, Qt 4.6.2, Gentoo Linux AMD64
>>
>>> I guess it's a driver issue. I'm currently using the open
>>> source ATI drivers (6.13.0) on X.Org server 1.7.6.
>>
>> No garbage here. My system's similar to yours, but there's some
>> differences which may be significant:
>>
>> * gentoo/~amd64 [with kde/xorg overlays]
>
> I'm running ~amd64, except that I masked xorg-server-1.8.0 (I can't deal
> with its newly introduced bugs right now, but I don't think the xorg
> version matters much anyway). Everything else is up to date.
Yeah, xorg-server 1.7.6 should be fine. I'd have 1.8.0 still masked as
well, had I not already found time to (semi-)grok the xorg.conf.d and no-
hal changes. FWIW, I was actually surprised at how easy it was.
It's /nothing/ like the monster that trying to program any custom config
into hal was!
So that shouldn't be it.
>> Now some info you didn't provide:
>>
>> * OpenGL based kde effects/compositing, with window transparency
>> enabled, but no drop-shadows.
> I'm using OpenGL compositing. I didn't set or change any transparency
> settings or shadows. The problem doesn't go away if I disable
> compositing completely.
OpenGL compositing, expected/good, my experience on the hd4xxx card I have
is that XRender's the one with bugs.
>> * mesa-7.8.1
>
> Same here.
So that's eliminated as a culprit.
>> * kernel: 2.6.34-rc4-54-g2ba3abd
>
> gentoo-sources-2.6.33-r1
That should be fine. As I said, you want/need at least 2.6.33, so that's
eliminated as a culprit.
>> * using KMS
>
> UMS here. KMS is very slow on my card (Radeon HD4870).
This is interesting. See below.
>> * all compiled with gcc-4.4.3
>
> Same here. CFLAGS="-pipe -g -mtune=core2 -march=core2 -O2"
Your CFLAGS are more conservative than mine (and yes, I /can/ explain why
I chose every one, at least to the level the manpage does):
CFLAGS="-march=opteron-sse3 -pipe -O2 -frename-registers -fweb
-fmerge-all-constants -fgcse-sm -fgcse-las -fgcse-after-reload
-ftree-vectorize -freorder-blocks-and-partition -combine"
NB: Setting -march implicitly sets -mtune as well, so there's no reason to
set both if you're using identical values. (This shouldn't be an issue
with your comparatively simple cflags, but I've seen people picked apart
for using it with a set of cflags like mine, for instance, with people
pointing out that not knowing the implications of -march can be seen as an
indication of not understanding the implication of other cflags one has
chosen to use as well.)
So with the tiny possible exception of a hardware optimization bug, gcc
and cflags should be eliminated as culprits.
>> * The graphics card is an AGP bus based Radeon hd4650, dual 1920x1200
>> monitors connected via DVI.
>
> PCI-e Radeon HD4870. Single monitor, 1280x1024, digital DVI-D
> connection.
OK, so you have a higher class GPU but still in the same family
(hd4870/rv770 vs hd4650/rv730), a newer bus (PCI-E vs AGP), and a lower
resolution, so you shouldn't be stressing the card as hard.
Barring GPU/driver specific quirks (the drivers are reasonably capable but
still new, after all), all should be fine there.
> I manually keep my world file to the bare minimum required.
FWIW, check out this output from emerge -a --depclean, here:
!!! You have no world file.
!!! Proceeding is likely to break your installation.
What? It's true, I have no world file at all, but contrary to the
warning, proceeding won't break my system. =:^)
I *DO* have a world_sets file (portage-2.2-rcX), and a few months ago when
I was reviewing the world file to see what parts of it I wanted to use for
my netbook installation, I split world into individual categorized sets
files for easier maintenance. Now, the only thing that the world file
occasionally contains is a new package or two I'm experimenting with, that
I've not yet moved to the appropriate set file. =:^)
>> * Check your KMS status and consider switching to it if you haven't.
>> You'll definitely want kernel 2.6.33 or later, tho, for KMS.
>
> As I stated above, KMS was extremely slow on my card last time I checked
> it out.
>
> I also tried the live ebuild of xf86-video-ati from the X11 overlay to
> get the latest ATI driver from Git. No change.
Now that they've released the ati 6.13.0 driver, with good kms and r600
driver OpenGL support, that's not as critical as it was before 6.13. But
it's worthwhile to check in any case.
Based on the above, there's only one major difference: KMS
You said "last time I checked" KMS, but didn't mention when that was.
Was it before kernel 2.6.33, before mesa-7.8.1, before xf86-video-
ati-6.13.0, and/or before xorg-server-1.7.6? If it was before any of
those, I'd suggest trying it again. KMS is going to be the recommended
config as all those versions work their way into the semi-annual
distribution releases (tho it's likely to be with kernel 2.6.34 and
possibly a bug-fix release or two on some of the other packages), and
that's clearly where things are headed, so ultimately, you're going to
need to do it.
The other detail that could make a difference is that "slow" or even
"extremely slow" is a relative term.
I've certainly found KMS usable here and have no desire to go back, for
sure. Occasionally, as when dragging a bunch of files around, with window
transparency effects kicking in as I switch windows, etc, KDE will popup
its "compositing was too slow, disabled, if the issue was temporary,
reenable it by..." message, but that's what it is, temporary, and I
normally reenable it quite soon.
If your "extremely slow" is relative to desktop usage such as that, then
there's certainly a bug somewhere, as my in-theory lower-end GPU in the
same family, running at a higher resolution, is most definitely workable,
definitely workable enough that the advantages of KMS are worth whatever
speed issues there might be.
OTOH, if you're a gamer and "extremely slow" is relative to loss of
framerate there, I'll have to say that's possible, even a known issue with
some hardware. But I'm not that much of a gamer, so I've no personal
experience to go on, there.
One other thing to try: Rebuild all the above, the kernel, mesa, xorg-
server, xf86-video-ati, plus libdrm (2.4.20 here, FWIW). There's a
particular order they need built in, and if you failed to rebuild them
after the last update, it's possible that one or another of the components
are still built against the older version of the others. Rebuilding them
all should ensure they're all built against current versions and may just
cure an issue or two. That's particularly true if you were running live-
git for a couple of the components, as I was for awhile, before the latest
releases with all the proper support finally available.
Oh, and one other thing: for Radeons, kernel 2.6.33 and onward is likely
to require a non-included gpu specific bit of firmware, before it'll work
with KMS at all. I know it did for me. In the kernel config:
Device drivers > Generic driver options > External firmware blobs to build
into the kernel binary:
Here, I had to set that to radeon/R700_rlc.bin .
Same config screen, Firmware blobs root directory:
/lib/firmware .
Thus, in /lib/firmware/radeon/, I have three firmware files, two as
included with the kernel, RV730_me.bin and RV730_pfp.bin (yours will
probably be RV770 files), and one that ships separately, R700_rlc.bin
(likely the same for both of us).
When I originally built the 2.6.33 kernel for KMS and tried to boot, it
failed with an error saying it couldn't find that firmware. I found the
file on the net and placed it appropriately, then rebuilt. It worked.
Since then I've read that the file may be included in the sys-kernel/linux-
firmware package, but I didn't have that package installed, and since I
already have that single firmware file placed in the appropriate location
manually, I didn't bother installing the package.
That's actually one of the big differences in KMS speed and stability for
the r700 series GPUs between kernel 2.6.32 and 2.6.33 -- the latter now
uses that bit of firmware, and it makes a *BIG* difference. If you do NOT
have that firmware and/or don't have your kernel configured to load it,
chances are very good that your last try at KMS was with 2.6.32. In that
case, it's *DEFINITELY* worth trying it with 2.6.33, and I think/hope
you'll be pleasantly surprised by how much improved KMS actually is, now.
And one more thing (yes, I know that's the third time I've said "one more
thing") about KMS. Ensure that you're NOT building in Radeon display
support (CONFIG_FB_RADEON should be unset or module) or VESA VGA graphics
support (CONFIG_FB_VESA), and that the modules aren't loaded when you try
kms, if you build them. Those framebuffer drivers conflict with KMS,
which uses its own driver.
> PS:
> Just before when I was about to hit the "send" button for this post, it
> occurred to me that there's one thing I didn't try: changing Qt's
> graphics system. The default on Gentoo is "native". When I start
> Konqueror with:
>
> konqueror -graphicssystem raster
>
> to switch from "native" to "raster", the bug goes away. No more
> glitches. However, raster results in slow as molasses performance,
> especially when scrolling. And I mean *really* slow and laggy.
I didn't think of the qt raster thing. Good thinking!
FWIW, tho, I have that USE flag off, here (qt-gui seems to be all that
uses it), and haven't done anything special with the qt config either, so
am still using the Gentoo "native" default. I did quickly try your
suggested commandline, tho, and don't have any unusual errors or anything
running it, tho didn't notice any difference in my admittedly very quick
test, either -- it wasn't dramatically slower or faster, to the point I'd
notice it that quickly, at least.
So that shouldn't be the issue, either, as we both seem to be running
native, not raster.
FWIW, however, the gentoo/kde project did discuss making raster the
default at I believe their last monthly meeting. From the coverage I
read, I /think/ they're planning on it now, but don't know when the change
will take place. Hopefully it won't be so slow for you after you trace
down whatever the issue is we're dealing with here, but a heads-up just in
case it remains so, to expect the Gentoo default may change. I'm not
/sure/ on that, but make note of it to the degree that it's now on my list
of things to check, with the next few versions, to see if they do change
it and how it works out when they do.
> So I guess it's a driver issue. Might be worth reporting it upstream
> (X.Org), but usually I don't since the reply you get is "use
> kernel/mesa/drilib/drm from Git", which I'm not prepared to do :P I'm
> using the machine for the sake of using it, not to turn it into a beta
> tester.
I understand. OTOH, the freedomware drivers support for OpenGL on this
hardware is /so/ new... By the end of the year, I expect things to be
settling down a bit as support matures. Meanwhile, there /are/ going to
continue to be occasional glitches with this hardware and drivers. The
alternatives are the binary drivers (not an option for me, I won't touch
them), or older hardware, r500 series vintage. Or just wait it out and be
patient as possible waiting for the drivers to mature a bit.
--
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.
