Bug 19010

Summary: [GM965 UXA GEM] Inkscape redraws extremely slow
Product: xorg Reporter: Ben Gamari <bgamari>
Component: Driver/intelAssignee: Eric Anholt <eric>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
A profile from OProfile none

Description Ben Gamari 2008-12-10 16:44:36 UTC
Canvas drawing in Inkscape is quite slow. It takes almost 2 seconds for a 1920x1200 window to draw.
Comment 1 Ben Gamari 2008-12-10 16:51:35 UTC
Created attachment 21026 [details]
A profile from OProfile
Comment 2 Ben Gamari 2008-12-10 18:28:32 UTC
Inkscape seems to be hitting a UXA fallback in uxa_copy_n_to_n.
Comment 3 Ben Gamari 2008-12-10 18:28:36 UTC
Xorg components as of Wed Dec 10 21:25:52 EST 2008
drm: 	c99566fb810c9d8cae5e9cd39d1772b55e2f514c
xf86-video-intel: 	83377b543defdca7226d7c1a7794e4ff3d8b4c84
mesa: 	a0d5c3cfe6582f8294154f6877319193458158a2
xserver: 	7c8720c1433d2c3b85bbf4b811cc54c2df4c0080

Linux mercury.localdomain 2.6.28-rc7 #6 SMP Tue Dec 9 19:36:02 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Comment 4 Eric Anholt 2008-12-16 21:54:15 UTC
With old cairo, I see cairo triggering fallbacks that suck 30% cpu resizing the blank canvas window.  With new cairo, that's gone, and I now see 5 different core rendering fallbacks, of which copy_n_to_n is one (though check_poly_fill_rect ranks higher).

I'm going to try a gtt mapping hack, which will probably cut the cost of a lot of fallbacks greatly.
Comment 5 Eric Anholt 2008-12-19 13:12:08 UTC
This should be fixed in
commit aae4008096399a0e84abc7c016b35092caf9db25
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Dec 17 14:25:22 2008 -0800

    uxa: Do a hack to use the aperture mapping instead of bo_map in sw fallbacks.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.