new radeon tiling patch

[Roland Scheidegger]

Michel Dänzer wrote:
>> I've uploaded a new version here: 
>> http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx8.diff
>> http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_dri8.diff
>> http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm8.diff
>> 
>> 
>> 
>> 
>> This one should have mergedfb + mixed interlaced/non-interlaced 
>> resolutions fixed (untested), fixed some errors with pageflip in 
>> some resolutions (backbuffer alignment problem),
> 
> 
> Speaking of mergedfb and page flipping: Is it really necessary to add
>  a new private SAREA field and a corresponding setparam? Isn't it 
> possible to set the generic SAREA fields as the DRM expects them, to
>  make this work with older DRMs as well?
Maybe, but I couldn't figure out a semi-sane way. The problem is those
values get set in the generic _DRIAdjustFrame in dri.c, which knows
nothing about mergedfb. It seems rather difficult to fix these values up
there without extending dri so it knows that there can be two viewports
looking into the same buffer (i.e. make it mergedfb-aware).
This solution also automatically gets rid of the need to recalculate the
offset in the case of color tiling (which isn't really a problem, but
why does drm have to redo it in the first place?).
Reports though unfortunately indicate that new sarea field solution
doesn't work neither for some reason (it works for color tiling, though)
:-(.

> What happened to Stephane's surface allocator, BTW? If you just whack
>  the surface registers directly from the X server, it becomes hard if
>  not impossible to introduce such an allocator, at least for the 
> surfaces touched directly by the X server...
Stephane told me it doesn't work yet. I thought about it briefly if it
would be a problem to introduce it later, and I don't think it is. For
all shared buffers, it seems to be ok that ddx would allocate the
surfaces. So it would just use the allocator instead of doing it
directly (in case of direct rendering, otherwise still needs to set it
up manually for the front buffer).
In an ideal world, surface allocation should probably be directly tied
to memory allocation.

>> If noone has objections, I'm going to commit this (minus some 
>> printfs) soon (consider yourself warned ;-)). Though I don't quite
>>  know if the drm/dri changes should also be applied to xorg cvs.
> 
> 
> If you do, please check with Eric or Adam or whoever knows about it 
> how to do it without messing up the vendor branches.
Will do.

> Also, I noticed the following comment:
> 
> 
>> +  /* note we cannot really simply use the 
>> info->ModeReg.crtc_offset_cntl value. +     if we do that we'll get
>>  rid of the flip_cntl bit the kernel has set for pageflipping. + 
>> This seems to cause some visual disturbance with some apps 
>> (glxgears) for some reason,
> 
> 
> Well, if you switch the roles of the front and back buffer several 
> times while one of them is being scanned out, you can see the clears
>  and rendering...
That explains it... so FLIP_CNTL needs to stay (only triple buffering 
could avoid that otherwise?).

> 
>> +     however disabling flip_cntl also gets rid of the flickering 
>> we get when hw scrolling +     in a virtual screen (since the crtc
>>  will pick up the new offset after each scanline, +     but it will
>>  only pick up the new offset_cntl value after a vsync). +     We'd
>>  probably need to wait for vsync somehow if we've scrolled before 
>> changing the +     offset to fix that flickering - unfixable ?*/
> 
> 
> The DRM could update the register in the vblank interrupt handler?
That sounds right (didn't know there was such a handler, but there it 
is...). I can't see how to do that though. Looks complicated :-(.

Roland