(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@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.

Should be fixed now:
52cc1dc1491559a9055f3ba6dd54064bb382ad86

Default size is 1600x1200; use a virtual line in your config to make it bigger.

Created attachment 10446 [details]
log with ColorTiling enabled

Created attachment 10447 [details]
log with color tiling disabled

sorry, still not fixed ....
Corrupted display with ColorTiling "1"



And I still need my hack in radeon_driver.c


#if 0                                                                           
    {                                                                           
        xf86CrtcConfigPtr   xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);          
        int i;                                                                  
        for (i = 0; i <= xf86_config->num_crtc; i++) {                          
                if (i == 0)                                                     
                        xf86_config->crtc[i]->enabled = 1;                      
                else                                                            
                        xf86_config->crtc[i]->enabled = 0;                      
        }                                                                       
    }                                                                           
#endif                                                                          
    RADEONUnblank(pScrn);   

// move RADEONUnblank(pScrn); outside if 0 ... endif

(without this my screen stay blank after VT switch to text console or server shutdown)

not sure about proper fix ....

should be fixed now as of:
6a3599d6155d073a3116c4b13bdf04b44bb9e087
stride was not properly set.

i using 7901bcafa92dccd319ddb5de4627d806a39f15f9 and main bug _still_ there ....

I tried 16 and 24 bit color depth - both broken ...

I have 48 pixels wide square flag (xxkb). If ColorTiling "ON" square broken into 8 chunks at first horizontal half of screen, and 8 another chunks [at one line] but slightly lower at another half of screen. If i use 16-bit depth i have only 8 chunks at horizontal, screen-wide, line.

xf86-video-ati, randr-1.2 branch, include 
commit bdcae622100c81a4d9a53938542b64908bacd195

after commented out line 226 in radeon_crtc.c 

save->crtc_offset_cntl = INREG(RADEON_CRTC_OFFSET_CNTL) & ~0xf;

tiling finally working!

Hm, something wrong with my git software?  Or something wrong with my hardware? Looks like i need all sorts of hacks only for making it work. Seriously, i fear all such blind hacking (like i did) may even damage other videocards....

(In reply to comment #8)
> xf86-video-ati, randr-1.2 branch, include 
> commit bdcae622100c81a4d9a53938542b64908bacd195
> 
> after commented out line 226 in radeon_crtc.c 
> 
> save->crtc_offset_cntl = INREG(RADEON_CRTC_OFFSET_CNTL) & ~0xf;
> 
> tiling finally working!
> 
> Hm, something wrong with my git software?  Or something wrong with my hardware?
> Looks like i need all sorts of hacks only for making it work. Seriously, i fear
> all such blind hacking (like i did) may even damage other videocards....
Highly unlikely...
And I think your solution is correct. This was wrong due to the code reshuffling, the inreg is at the wrong place, but the code doesn't seem to rely on any values already set, so it can go. Apart from that, the issue mentioned in the comment (the scrolling in a virtual screen causing headaches) doesn't exist with randr anyway, as that feature isn't supported at all.
I think you're just discovering these bugs because not too many people are using the randr 1.2 branch with pre-r300 radeons right now.

This should be fixed now.  Thanks for your help!