Created attachment 88213 [details]
perf report for bad commit

Created attachment 88214 [details]
perf report for good commit

Created attachment 88217 [details]
perf report for bad commit

This is an artifact of sending damage events to the compositor quicker. I suspect the issue is that the compositor is rendering more frames during the test rather than the overhead of sending more often, i.e. notabug.

(In reply to Chris Wilson from comment #4)
> This is an artifact of sending damage events to the compositor quicker. I
> suspect the issue is that the compositor is rendering more frames during the
> test rather than the overhead of sending more often, i.e. notabug.

So this needs to be tested without compositor.  Setting as needinfo.

"The problem doesn’t exist on Raw X."

The only question is whether the impact is acceptable - I think so, since this should be mitigated in the compositor and is a fairly extreme case.

> This is an artifact of sending damage events to the compositor quicker. I suspect the issue is that the compositor is rendering more frames during the test rather than the overhead of sending more often

I don't follow how just reducing damage event latency would cause more frames to be rendered, unless damage events were earlier clumped more together, so that single compositor update handled multiple events, and now the events are more spread out so that they get handled separately.

To validate the assumption of damage events causing the issue, one could e.g. check with xresponse [1] whether the number or timing of damage events changed.

[1] https://maemo.gitorious.org/maemo-tools/xresponse


But if you know what the related changes were and are sure it was latency reduction, notabug sounds fine too.

(In reply to Eero Tamminen from comment #7)
> > This is an artifact of sending damage events to the compositor quicker. I suspect the issue is that the compositor is rendering more frames during the test rather than the overhead of sending more often
> 
> I don't follow how just reducing damage event latency would cause more
> frames to be rendered, unless damage events were earlier clumped more
> together, so that single compositor update handled multiple events, and now
> the events are more spread out so that they get handled separately.

Yes, that was exactly the change. I think the culprit is

commit 9bf46610a9d20962854016032de4567974e87957
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jun 21 22:58:31 2013 +0100

    os: Immediately queue initial WriteToClient

which would have had the effect of sending more damage events to the compositor. And if the compositor was not coalescing them back to the equivalent of the earlier stream, it would process more frames. (E.g. if it was effectively doing a do { while(read(X)) accumulate(); render(); } while(1), it would be processing more work than if it just rendered at a maximum frequency.)

The other aspect of that change was that it affected cpufreq and process placement across cores.

> To validate the assumption of damage events causing the issue, one could
> e.g. check with xresponse [1] whether the number or timing of damage events
> changed.
> 
> [1] https://maemo.gitorious.org/maemo-tools/xresponse

Sounds like a useful tool to build into out testing...

> But if you know what the related changes were and are sure it was latency
> reduction, notabug sounds fine too.

Hello Eero,

I have not access right to download the xresponse tool:

[root@wendy-linux xresponse]# tsocks git clone git@gitorious.org:maemo-tools/xresponse.git
Cloning into 'xresponse'...
The authenticity of host 'gitorious.org (87.238.52.168)' can't be established.
RSA key fingerprint is 7e:af:8d:ec:f0:39:5e:ba:52:16:ce:19:fa:d4:b8:7d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gitorious.org,87.238.52.168' (RSA) to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Hello Chris and Eero,
I can download the xresponse tool now.
But which kind of scenario you'd suggest to catch using xresponse? mouse click, drag or others?

Then pls guide me which commits should be measured? Both before and after culprit commit?

commit 9bf46610a9d20962854016032de4567974e87957
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jun 21 22:58:31 2013 +0100

    os: Immediately queue initial WriteToClient

Thanks.

(In reply to wendy.wang from comment #10)
> Hello Chris and Eero,
> I can download the xresponse tool now.
> But which kind of scenario you'd suggest to catch using xresponse? mouse
> click, drag or others?
> 
> Then pls guide me which commits should be measured? Both before and after
> culprit commit?

You would need to check average interval between XDamage events during the test-run, from output of:
  xresponse -a '*' -w 0

(monitored applications (-a) are all (=*), wait (-w) infinitely (=0))

Run the program from ssh console so that its output doesn't disturb your testing.  For that output you can also see if something else is doing screen updates (e.g. panel applets).


I checked x11perf a bit in my Ubuntu.  I don't see XDamage events for x11perf window itself, maybe because it's override redirect.  I do seem them for compositor though (SCREEN ones in xresponse output).

x11perf window size is 600x600, and resulting Unity compositor updates on screen are fullscreen according to XDamage events (no partial screen update support).  With Unity, those screen updates do happen at ~60 FPS (= at ~17ms interval).

Wendy, what is the average update interval with your gnome-session?


(In reply to Chris Wilson from comment #8)
> Yes, that was exactly the change. I think the culprit is
> 
> commit 9bf46610a9d20962854016032de4567974e87957
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Fri Jun 21 22:58:31 2013 +0100
> 
>     os: Immediately queue initial WriteToClient
> 
> which would have had the effect of sending more damage events to the
> compositor.

Ok, so there are actually more of them, they aren't just (potentially) spread (time-wise) differently.


> And if the compositor was not coalescing them back to the
> equivalent of the earlier stream, it would process more frames. (E.g.
> if it was effectively doing a do { while(read(X)) accumulate(); render(); }
> while(1), it would be processing more work than if it just rendered at a
> maximum frequency.)

Compositor not coalescing the events, would be a (performance) bug in the compositor.

Wendy, if that is the case (SCREEN updates happen more frequently than 60 FPS), *and* that is not fixed in latest version of the gnome-session compositor, file a bug to upstream about it.   We don't want to debug compositor issues.

Test on HSW and IVB-Mobile, aa10text performance is working and normal with latest GFX SW stack, so close this bug as works for me.

 Libdrm:		(master)libdrm-2.4.61
 Mesa:		(master)971be2b7c9c4459e383059f02d20a35e469b429e
 Xserver:		(master)xorg-server-1.17.0-130-g0409b6e6d63e9cfb5dc71bb27de4b1ed0152dd9b
 Xf86_video_intel:		(master)2.99.917-296-g5054e2271210a52bf88b0f12c35d687ce9e8210d
 Cairo:		(master)2cf2d8e340a325adb205baf8e4bd64e1d1858008
 Libva:		(master)9bfde38f19d81b7f33db8c4c8e80420c9e60429e
 Libva_intel_driver:		(master)0f20a46c91c71e0a5d10eef36aef8d8799361184
 Kernel:   (drm-intel-nightly)7dcedb8e7bbf49f1342df21851d9b36786ff67ce