new radeon tiling patch

[Roland Scheidegger]

Michel Dänzer wrote:
> On Tue, 2005-01-18 at 15:43 +0100, Roland Scheidegger wrote:
> 
>> Michel Dänzer wrote:
>> 
>>> 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.
> 
> 
> Hmm... I was hoping that DRIAdjustFrame() would call the wrapped 
> function (ultimately the driver's AdjustFrame() hook) last, as most 
> wrapper functions seem to do, but apparently it doesn't. :( Still, 
> the driver should be able to wrap around DRIAdjustFrame() again after
>  it's been installed, and the wrapper could fix up the generic SAREA 
> fields as needed. I agree that's not exactly an elegant solution, but
>  I think it's still better than requiring users to upgrade the DRM to
>  get this working.
Everyone should update anyway to get color tiling working ;-).
As a simpler fix, would it be safe to simply change the order of the
calls to the wrapped function and _DRIAdjustFrame() in dri.c? That would
definitely change the semantic of the function, but I don't know if it
would actually hurt. Ah well maybe not a very good idea.
I'll give the double-wrap a try, should also work for tiling, if some
creative frame.y and frame.x values are put there (I'm not too keen on
redoing the calculation in the drm again).

> 
> 
>>> 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).
> 
> 
> But (how) will the DRM surface allocator detect an old DDX that 
> doesn't know about it and touches the surface registers directly and 
> deal with it?
Argh. Well, maybe require dri drivers to query for ddx minor version
and not use it if they detect an old version? Sounds like a kludge.
Maybe it would be worth to integrate it now.

>>> 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 
>> :-(.
> 
> 
> I guess it would require yet another ioctl/setparam/SAREA field.
Hmpf, I hate pageflip :-(. In an ideal world, only ddx or drm would mess 
with offset and offset_cntl, not both :-(.
I don't consider that a show-stopper, though.

Roland