Bug 22496

Summary: [945GME] Severe performance regression, rdesktop with vector graphics
Product: DRI Reporter: Anthony Horton <ajh>
Component: DRM/IntelAssignee: Carl Worth <cworth>
Status: CLOSED INVALID QA Contact:
Severity: normal    
Priority: medium CC: magnus.lidbom
Version: unspecifiedKeywords: regression
Hardware: All   
OS: Linux (All)   
URL: https://bugzilla.redhat.com/show_bug.cgi?id=486065
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log from older 915GM system which does not exhibit the problem
none
Xorg.0.log from newer 945GME system which does exhibit the problem none

Description Anthony Horton 2009-06-26 06:52:38 UTC 
Description of problem:

rdesktop's rendering performance when vector graphics are present is extremely
slow, to the point of making rdesktop unusable.  Performance is good when only
text and bitmap graphics are being displayed by the remote Windows machine but
when I run an application which uses vector graphics (in my case ZEMAX)
redrawing of windows becomes very slow.  It can take up to several minutes for
a single vector graphics window to redraw, during which time the remote system
will be completely unresponsive and rdesktop will be using 100% CPU on the
local machine.  You can actually see diagrams being drawn one line at a time.  

A variety of engineering/scientific software uses vector graphics for display
of diagrams/plots/drawings/etc. but while this performance issue remains they
are essentially unusable over an rdesktop connection.  

This problem is not present with older software.

How reproducible: Always

Steps to Reproduce:
1. Connect to a Windows server using rdesktop
2. Open a application which uses vector graphics (e.g. ZEMAX, free demo version
available from http://www.zemax.com).
3. Display some vector graphics (e.g. ZEMAX 3d layout or spot diagrams)

Actual results:

Each redraw of a window including vector graphics is extremely slow.

Expected results:

Redraws of vector graphics windows take comparable times to bitmap
graphics/text/etc.

Additional info:

This is still an issue on this hardware with Fedora 11.  There appears to be
some improvement in performance compared to F10, however the redraw time for a
rdesktop connection to a vector graphics using application with current drivers
and 945GME hardware is still at least an order of magnitude slower than the
same application when viewed from a 4 year old 915GM laptop running Centos 4. 
This performance regression is so severe as to make rdesktop unusable for
vector graphics using applications.

Unsuable system (Asus EeePC 901 w/ F11):

Intel 945GME graphics
xorg-x11-drv-intel-2.7.0-7.fc11.i586
mesa-dri-drivers-7.5-0.14.fc11.i586
kernel-PAE-2.6.29.5-191.fc11.i686
libdrm-2.4.6-7.fc11.i586
rdesktop-1.6.0-4.fc11.i586
xorg-x11-server-Xorg-1.6.1.901-1.fc11.i586

Usable system:

Intel 915GM graphics
Centos 4/RHEL 4 graphics drivers
rdesktop-1.6.0-0.1.el4.rf
Comment 1 Gordon Jin 2009-06-28 18:57:10 UTC 
>> This problem is not present with older software.
Can you provide the specific version of "older software", e.g. xf86-video-intel, xserver, and kernel.
Comment 2 Anthony Horton 2009-06-28 19:28:31 UTC 
Created attachment 27211 [details]
Xorg.0.log from older 915GM system which does not exhibit the problem

(In reply to comment #1)
> >> This problem is not present with older software.
> Can you provide the specific version of "older software", e.g.
> xf86-video-intel, xserver, and kernel.

The older software is very much older I'm afraid, but it's the only system I have readily available for comparison.  I'm wary about updating as it is currently the only system I have that handles rdesktop w/ remote ZEMAX properly.

It's a Centos4 machine, 915GM hardware, monolithic X.Org:

kernel-2.6.9-78.0.13.EL
xorg-x11-6.8.2-1.EL.52
rdesktop-1.6.0-0.1.el4.rf

X.Org 6.8.2 uses the i810 driver module, version 1.3.0.  

I've attached the Xorg.0.log from this older system for full module version information.
Comment 3 Anthony Horton 2009-06-28 19:37:19 UTC 
Created attachment 27212 [details]
Xorg.0.log from newer 945GME system which does exhibit the problem

Here is the Xorg.0.log from the system which does have the problem (Asus Eee PC 901, 945GME graphics, Fedora 11).  I'm not using an /etc/X11/xorg.conf at present, I'm allowing X.Org to automatically configure itself.
Comment 4 Chris Wilson 2009-12-02 11:52:50 UTC 
Anthony, this is complicated by the requirement of a Windows machine...

In order to understand the problem can you capture an xtrace of the traffic rdestop is sending, and in particular how this changes between bitmap and vector apps?
Comment 5 Chris Wilson 2010-07-02 13:25:44 UTC 
The description seems to imply that we are hitting severe fallback ping-pong for which a plain fb would indeed be measurably faster. Without any information to ascertain the nature of the fallback, it is impossible for us to fix it. However, I do hope the improvements we have made to i915 accelerated performance should alleviate this issue. Please do reopen this bug report if you can show which pathways are at fault - a profile from of the driver should be enough for us to work out what is going on.
Comment 6 Jari Tahvanainen 2016-11-03 08:13:17 UTC 
Closing resolved+invalid, no activity on more than 6 years.

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.