new radeon tiling patch

[Michel Dänzer]

On Mon, 2005-01-17 at 21:34 +0100, Roland Scheidegger wrote:
> Michel Dänzer wrote:
> > On Sat, 2005-01-15 at 03:29 +0100, Roland Scheidegger wrote:
> > 
> > The location of the framebuffer as seen by the
> > GPU needs is defined by MC_FB_LOCATION. All current components have
> > fields named along the lines of ...->fbLocation for that.
> I've done some tests, and this doesn't seem to be true for the surface 
> regs. Maybe the addresses there are already relative to MC_FB_LOCATION.

Yeah, that makes sense, as the surfaces only apply to CPU access, and
the GPU can only affect that for the framebuffer.


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

> fixed a copy & paste error in the non-core drm version, and it actually 
> auto-refreshes the screen when switching between a tiled and untiled resolution...

Nice.

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


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


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

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


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