A question about "Software rendering for gnome-shell"

[mwesten]

On 02/23/2012 09:54 AM, Adam Jackson wrote:
> On Thu, 2012-02-23 at 08:44 -0500, mwesten wrote:
>
>> Fedora-17-Alpha-i686-Live-Desktop.iso (RC2) on USB
>>
>> 2.13GHz AthlonXP 2600+ / RV200 (Radeon 7500) / 1280x1024
>>
>> Fallback mode is fine, but once the shell starts, it's a battle just to
>> get System Monitor open and to the Resources tab.  Once there, the CPU
>> sits at 100% until I get off that tab.  Very high latency, screen
>> flickering, artifacts, incomplete rendering...
>
> "Incomplete" is worrisome, I've not seen that.

OK, let me (try to) clarify all that with an example.

Say I have a terminal window open.  I click and drag it somewhere.
A few seconds later, it "jumps" to the new location.
Then it quickly jumps back to where it started.
Sometimes it just leaves a piece behind, and other times the whole 
window reappears at the new location, so there are two. (!)
Switching modes or bouncing out to a VC and back will make it redraw 
correctly.

This is only on the *really* slow one now (RV200).  The others don't do 
any of whatever that is...
>
> There's a bit of a quantum effect here where the act of drawing the CPU
> monitor necessarily raises CPU load.  If you ssh into the machine and
> run top from there, gnome-shell and Xorg shouldn't be taking any undue
> load at idle.  If they are, that means there's rendering happening at
> idle, which is a legitimate bug that would affect even accelerated
> drivers by keeping the GPU from going to sleep to save power.

I'm just using the monitor as an easy way of loading and comparing the 
systems.  I did check and the idle load is very low, so no issue there.
>
> In the non-steady-state, though, the current implementation is known to
> be incredibly memcpy-heavy.  Fixes coming soon, beta should be much
> better I hope.  If you want to collect some data about where CPU time is
> being spent, 'perf record' against the X server or gnome-shell (with
> debuginfo installed) and then 'perf report' should be enlightening.  I
> suspect you'll find the vast majority of the time spent in memcpy in one
> form or another (pixman or fb blit, copying data into and out of the
> kernel across the unix socket, etc).

I'll see what I can do.

-Mike