I've noticed a general slowdown of XAA on Radeon when DRI is
enabled. This is in our XFree86-4.1.0-3 package that shipped
with Red Hat Linux 7.2.
If DRI is disabled by commenting out the "dri" and "GLcore"
module load lines in XF86Config-4, then 2D acceleration flies.
Re-enabling DRI however makes 2D very painfully slow. I never
noticed it much as I normally have DRI disabled on my workstation
for "work", and only restart with DRI to test 3D accel or have a
quick game, etc.
Nobody else has reported this problem to me via bugzilla, email,
or IRC, and most people seem to not notice any difference in 2D
speed wether or not DRI is enabled or disabled.
So I thought perhaps it was just the particular hardware combo I
am using. Unfortunately I could reproduce this on any system I
have here, even though others have claimed to not be able to
reproduce.
A unified diff of a log file with DRI disabled versus with DRI
enabled shows:
-(II) RADEON(0): Memory manager initialized to (0,0) (1600,8191)
+(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0"
+(II) RADEON(0): [drm] added 4096 byte SAREA at 0xf8d8c000
+(II) RADEON(0): [drm] mapped SAREA 0xf8d8c000 to 0x40017000
+(II) RADEON(0): [drm] framebuffer handle = 0xf0000000
+(II) RADEON(0): [drm] added 1 reserved context for kernel
+(II) RADEON(0): [agp] Mode 0x1f000209 [AGP 0x1166/0x0008; Card 0x1002/0x5144]
+(II) RADEON(0): [agp] 8192 kB allocated with handle 0xfcd8f000
+(II) RADEON(0): [agp] ring handle = 0xc0000000
+(II) RADEON(0): [agp] Ring mapped at 0x44255000
+(II) RADEON(0): [agp] ring read ptr handle = 0xc0101000
+(II) RADEON(0): [agp] Ring read ptr mapped at 0x40018000
+(II) RADEON(0): [agp] vertex/indirect buffers handle = 0xc0102000
+(II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x44356000
+(II) RADEON(0): [agp] AGP texture map handle = 0xc0302000
+(II) RADEON(0): [agp] AGP Texture map mapped at 0x44556000
+(II) RADEON(0): [drm] register handle = 0xfe580000
+(II) RADEON(0): [dri] Visual configs initialized
+(II) RADEON(0): CP in BM mode
+(II) RADEON(0): Using 8 MB AGP aperture
+(II) RADEON(0): Using 1 MB for the ring buffer
+(II) RADEON(0): Using 2 MB for vertex/indirect buffers
+(II) RADEON(0): Using 5 MB for AGP textures
+(II) RADEON(0): Memory manager initialized to (0,0) (1600,2514)
(II) RADEON(0): Reserved area from (0,1200) to (1600,1202)
-(II) RADEON(0): Largest offscreen area available: 1600 x 6989
+(II) RADEON(0): Largest offscreen area available: 1600 x 1312
+(II) RADEON(0): Reserved back buffer at offset 0xf5a000
+(II) RADEON(0): Reserved depth buffer at offset 0x16ad000
+(II) RADEON(0): Reserved 34816 kb for textures at offset 0x1e00000
(==) RADEON(0): Backing store disabled
(==) RADEON(0): Silken mouse enabled
(II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
- 8x8 mono pattern filled rectangles
- Indirect CPU to Screen color expansion
- Solid Lines
- Dashed Lines
- Scanline Image Writes
+ Solid Horizontal and Vertical Lines
Offscreen Pixmaps
Setting up tile and stipple cache:
32 128x128 slots
- 32 256x256 slots
- 16 512x512 slots
+ 22 256x256 slots
(II) RADEON(0): Acceleration enabled
The above shows that when using DRI, many XAA features just
disappear. This has got to be the cause of the slowdown I have
noticed. Investigating the radeon_accel.c code reveals that,
when DRI is enabled, 2D acceleration is implemented through DRI
as well, however it appears that many of the XAA features are not
implemented using this method, the result being that 2D
performance takes a huge blow when using DRI.
RADEONMMIOAccelInit() gets used when DRI is disabled, whereas
RADEONCPAccelInit() gets used when DRI is enabled. The code in
the latter, hooks with a lot less 2D stuff than does the former.
I compared this with the current trunk code, and it appears more
2D stuff is now implemented in the trunk for the DRI enabled
case, which is cool, but still not all functionality of the MMIO
code yet.
Is anyone currently working on improving the 2D accel code for
Radeon, either with or without DRI? I might be interested in
playing with it, if nobody is currently working on it, or
planning to soon.
Any comments are greatly appreciated.
TIA
--
----------------------------------------------------------------------
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer Ontario, Canada, P6C 5B3
Red Hat Inc. Phone: (705)949-2136
http://www.redhat.com ftp://people.redhat.com/mharris
Red Hat XFree86 mailing list: [EMAIL PROTECTED]
General open IRC discussion: #xfree86 on irc.openprojects.net
----------------------------------------------------------------------
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
