Bug 29333

Summary: [r300] dual head output is *very* slow on rotated display
Product: xorg Reporter: Till Matthiesen <entropy>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED NOTOURBUG QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Till Matthiesen 2010-07-31 04:59:08 UTC
Hi all,

I'm using using libdrm, mesa [r300g] and xf86-video-ati from git.

The setup I'm facing the issue with is a Thinkpad R50p with r300 class GPU [AGP].

When I use the internal display together with an external display [D-Sub] which is rotated the output on the external display is *extremely* sluggish. You can watch the screen being build up. Honestly, it takes the external screen 1-2 seconds to finish refresh. It's currently simply not possible to work in this configuration for me.

xrandr:

Screen 0: minimum 320 x 200, current 2880 x 1200, maximum 4096 x 4096
VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0  
   1280x960       75.0     60.0  
   1152x864       75.0  
   1024x768       75.1     70.1     60.0                                                                                                                                         
   832x624        74.6                                                                                                                                                           
   800x600        72.2     75.0     60.3     56.2                                                                                                                                
   640x480        72.8     75.0     66.7     60.0                                                                                                                                
   720x400        70.1  
DVI-0 disconnected (normal left inverted right x axis y axis)
LVDS connected 1600x1200+1280+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1600x1200      60.0*+   60.0  
   1400x1050      60.0     60.0  
   1280x1024      59.9     60.0  
   1440x900       59.9  
   1280x960       60.0     59.9  
   1280x854       59.9  
   1280x800       59.8  
   1280x720       59.9  
   1152x768       59.8  
   1024x768       60.0     59.9  
   800x600        60.3     59.9  
   848x480        59.7  
   720x480        59.7  
   640x480        59.9     59.4  
S-video disconnected (normal left inverted right x axis y axis)

lspci:

01:00.0 VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2] (rev 80) (prog-if 00 [VGA controller])
        Subsystem: IBM Device 054f
        Flags: bus master, fast Back2Back, 66MHz, medium devsel, latency 66, IRQ 11
        Memory at e0000000 (32-bit, prefetchable) [size=128M]
        I/O ports at 3000 [size=256]
        Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at c0120000 [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
        Capabilities: [50] Power Management version 2
        Kernel driver in use: radeon
        Kernel modules: radeon

Configuration of the displays:
 xrandr --output LVDS --mode 1600x1200 --right-of VGA-0
 xrandr --output VGA-0 --mode 1280x1024 --rotate left

Thanks in advance and keep up the excellent work!
Comment 1 Alex Deucher 2010-07-31 07:53:42 UTC
The problem is your total desktop (2880 pixels) is larger than that max texture size of the GPU (2048 pixels), so it has to fall back to software when doing the rotation.  The only way to fix it is to teach X to treat each head as a separate buffer rather than using one big buffer for both heads.
Comment 2 Till Matthiesen 2010-07-31 14:14:52 UTC
(In reply to comment #1)
> The problem is your total desktop (2880 pixels) is larger than that max texture
> size of the GPU (2048 pixels), so it has to fall back to software when doing
> the rotation.  The only way to fix it is to teach X to treat each head as a
> separate buffer rather than using one big buffer for both heads.

Thanks, Alex.

I see, so my bad.

Just as a suggestion, wouldn't it be useful to log this kind of fall back in Xorg.0.log? I don't know about the maximum texture size an asic has and I guess lots of others might not as well.

This would at least give a clear hint on what is wrong.

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.