On 6/30/05, Aapo Tahkola <[EMAIL PROTECTED]> wrote:
> On Wed, 29 Jun 2005 22:07:35 -0400
> Alex Deucher <[EMAIL PROTECTED]> wrote:
> 
> > On 6/29/05, Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> > > Hamish Marson wrote:
> > > > Fixed it.
> > > >
> > > > Sorry. It isn't an r300 problem... Or at least doesn't LOOK like an
> > > > r300 problem. I changed the xorg.conf & set
> > > >
> > > >         Option     "EnablePageFlip" "on"       # [<bool>]
> > > >
> > > > to
> > > >
> > > >         Option     "EnablePageFlip" "off"       # [<bool>]
> > > >
> > > >
> > > > and the flickering went away...
> > >
> > > PageFlip should work usually on radeons (there can be issues when you
> > > use it together with tiling, see
> > > https://bugs.freedesktop.org/show_bug.cgi?id=2604), but since the r300
> > > driver doesn't support tiling yet...
> > > Though I don't know if pageflip is actually supposed to work on r300
> > > based cards currently, I don't think there should be differences to the
> > > other radeons in that area.
> > >
> >
> > I just added tiling support for r3/4xx cards to xorg cvs.
> 
> Nice!
> Couple fixes to get depth reads/writes working with 16 and 32 bit depth 
> buffers:
> 
> diff -uNr atissss/radeon_driver.c ati..s/radeon_driver.c
> --- atissss/radeon_driver.c     Thu Jun 30 05:51:54 2005
> +++ ati..s/radeon_driver.c      Thu Jun 30 06:06:49 2005
> @@ -6110,8 +6110,13 @@
>             depth_pattern = RADEON_SURF_TILE_DEPTH_16BPP;
>         else
>             depth_pattern = RADEON_SURF_TILE_DEPTH_32BPP;
> -    }
> -    else {
> +    } else if (IS_R300_VARIANT){
> +       color_pattern = R300_SURF_TILE_COLOR_MACRO;
> +       if (cpp == 2)
> +           depth_pattern = R300_SURF_TILE_COLOR_MACRO;
> +       else
> +           depth_pattern = R300_SURF_TILE_COLOR_MACRO | 
> R300_SURF_TILE_DEPTH_32BPP;
> +    } else {
>         /* no idea about R300, just set it up the same as r200
>            if someone is crazy enough to try... */
>         color_pattern = R200_SURF_TILE_COLOR_MACRO;
> @@ -6175,7 +6180,12 @@
>             drmRadeonSurfaceAlloc drmsurfalloc;
>             drmsurfalloc.size = bufferSize;
>             drmsurfalloc.address = info->depthOffset;
> -           drmsurfalloc.flags = swap_pattern | (width_bytes / 16) | 
> depth_pattern;
> +
> +           if (IS_R300_VARIANT)
> +               drmsurfalloc.flags = swap_pattern | (width_bytes / 8) | 
> depth_pattern;
> +           else
> +               drmsurfalloc.flags = swap_pattern | (width_bytes / 16) | 
> depth_pattern;
> +
>             retvalue = drmCommandWrite(info->drmFD, DRM_RADEON_SURF_ALLOC,
>                 &drmsurfalloc, sizeof(drmsurfalloc));
>             if (retvalue < 0)
> diff -uNr atissss/radeon_reg.h ati..s/radeon_reg.h
> --- atissss/radeon_reg.h        Thu Jun 30 05:51:53 2005
> +++ ati..s/radeon_reg.h Thu Jun 30 06:06:53 2005
> @@ -1314,6 +1314,9 @@
>  #       define R200_SURF_TILE_COLOR_BOTH    (3 << 16)
>  #       define R200_SURF_TILE_DEPTH_32BPP   (4 << 16)
>  #       define R200_SURF_TILE_DEPTH_16BPP   (5 << 16)
> +#       define R300_SURF_TILE_NONE          (0 << 16)
> +#       define R300_SURF_TILE_COLOR_MACRO   (1 << 16)
> +#       define R300_SURF_TILE_DEPTH_32BPP   (2 << 16)
>  #       define RADEON_SURF_AP0_SWP_16BPP    (1 << 20)
>  #       define RADEON_SURF_AP0_SWP_32BPP    (1 << 21)
>  #       define RADEON_SURF_AP1_SWP_16BPP    (1 << 22)
> 

I can apply those to cvs tonight.

> Please note that I havent tested this with current xorg cvs because of 
> various inconveniences.
> What about the 2560 limit?
> I noticed that with the new RADEONDoAdjustFrame I can have 
> 1280x1024-1280x1024 setup if I remove the limits.

I assume you are talking about the limits of the surface regs.  I'll
check the databooks tonight and see if I can figure out what they
should be.  Apparently the fglrx driver allows 2560, but that would
seem to require an extra half bit of address or something.  Maybe it's
actually 12 bits, but they limit you to 2560 for bandwidth reasons...

Alex

> 
> > Pageflipping won't work for r300 until the sarea and drm are updated
> > to handle the additional xytiling regs.
> 
> I fixed couple of things with it and it should now work.
> Its not very stable at least with tiling enabled(havent tested without) 
> though im afraid.
> 
> --
> Aapo Tahkola
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to