new radeon tiling patch

[Michel Dänzer]

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.


> > 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?

> In an ideal world, surface allocation should probably be directly tied
> to memory allocation.

Yeah, one problem being that surfaces are scarce...


> >> +     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 :-(.

I guess it would require yet another ioctl/setparam/SAREA field.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer