Xorg 7.0-rc1 and EXA (radeon 9200)

[Pierre Ossman]

Michel Dänzer wrote:
> On Mon, 2005-10-24 at 23:32 +0000, morgoth6 at box43.pl wrote:
>>> No, GNOME is usually snappy here, running xcompmgr -a.
>> Also any GTK+ apps are deam slow under KDE for example. Hmmm weird ... 
> 
> Indeed. BTW, I'm also using 2.12, GTK+ 2.8.6 and Cairo 1.0.2, so it
> doesn't seem to be either of these in general, unless we have different
> definitions of 'snappy' vs. 'dead slow' maybe... Have you tried
> disabling sub-pixel AA in GNOME to see if it makes more of a difference
> there than in KDE?
> 

I'm using the same versions and the behaviour is both 'snappy' and 'dead 
slow' here. :)

For most windows it runs very well, but sometimes it crawls to a halt. 
The desktop window (the root nautilus window) is, more or less, always 
like this. Other windows usually get this way when there are many 
windows open at the same time. So it might be memory related.

Sub-pixel AA is _really_ slow here (see bug 4668), but disabling it has 
no effect on anything but large text-rendering applications.

Afraid I don't have KDE installed, so I can't try that.

> 
>>> Sounds like SW cursor is being used instead of HW cursor. There's a
>>> known issue where the radeon driver with EXA sometimes (in particular
>>> after a VT switch) drops back from HW cursor to SW cursor, without any
>>> sign of it in the log file.
>> Is there a way to verify which cursor mode is used in a moment ?
> 
> Mostly by watching the behaviour of the cursor and its surroundings,
> e.g. watch for the cursor flickering when its surroundings are updated,
> e.g. when scrolling the window beneath it. Also, when using
> direct-rendered OpenGL, the SW cursor will disappear in the 3D window
> and only shortly re-appear when you move it.
> 

That happens here constantly. So if someone needs a tester I'm willing 
and able. :)

(Strangely enough I have a bug here than only appears with HW cursor 
(bug 4633), but I guess that might be before it falls back to SW.)

Rgds
Pierre