[Bug 11357] Color tiling with randr-1.2 branch broken on rv280

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sun Jun 24 15:41:15 PDT 2007


http://bugs.freedesktop.org/show_bug.cgi?id=11357





------- Comment #1 from sroland at tungstengraphics.com  2007-06-24 15:40 PST -------
(In reply to comment #0)
> So, according to these articles - Frame Buffer tiling is important for 2D and
> 3D performance. And yes, on my low-end consumer card with slow memory
> 
> (--) RADEON(0): Mapped VideoRAM: 65536 kByte (64 bit DDR SDRAM)
> 
> I can actually see difference in 3d apps (2x-2.5x slowdown in quake3,
> resolution 1024x768 at 75hz, 24 bit. Quake3 is my standard 3d app for finding
> basic regressions in 3d), 2d performance still acceptable, but this may be
> because fast CPU (celeron-1700).
I've never seen tiling really make a difference for 2d with radeons, you can
measure a difference with some benchmarks but it's nothing you'd care.

> vs info->MaxSurfaceWidth = 2048; info->MaxLines = 2048 in radeon_driver.c) -
> may be this is source for my problems? As far as i known - current radeon
> randr-1.2 driver over allocated all buffers (include framebuffer) just in case
> there will be second monitor attached later - but i can't find in source files 
> how i can override this. (and all randr-1.2 fun will be off if i'll do such
> thing). 
Yes, I'd suspect there is something wrong with the code detecting if tiling can
be enabled or not in the randr branch.
The size it sets is with the xf86CrtcSetSizeRange call in radeon_driver.c if
you stick to something below 2048 instead of the 2708 maybe tiling works again.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


More information about the xorg-driver-ati mailing list