From: Alex D. <ale...@gm...> - 2005-06-30 13:08:30
|
On 6/30/05, Aapo Tahkola <ae...@ra...> wrote: > On Wed, 29 Jun 2005 22:07:35 -0400 > Alex Deucher <ale...@gm...> wrote: >=20 > > On 6/29/05, Roland Scheidegger <rsc...@hi...> 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=3D2604), but since the r= 300 > > > 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 t= he > > > other radeons in that area. > > > > > > > I just added tiling support for r3/4xx cards to xorg cvs. >=20 > Nice! > Couple fixes to get depth reads/writes working with 16 and 32 bit depth b= uffers: >=20 > 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 =3D RADEON_SURF_TILE_DEPTH_16BPP; > else > depth_pattern =3D RADEON_SURF_TILE_DEPTH_32BPP; > - } > - else { > + } else if (IS_R300_VARIANT){ > + color_pattern =3D R300_SURF_TILE_COLOR_MACRO; > + if (cpp =3D=3D 2) > + depth_pattern =3D R300_SURF_TILE_COLOR_MACRO; > + else > + depth_pattern =3D 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 =3D R200_SURF_TILE_COLOR_MACRO; > @@ -6175,7 +6180,12 @@ > drmRadeonSurfaceAlloc drmsurfalloc; > drmsurfalloc.size =3D bufferSize; > drmsurfalloc.address =3D info->depthOffset; > - drmsurfalloc.flags =3D swap_pattern | (width_bytes / 16) | de= pth_pattern; > + > + if (IS_R300_VARIANT) > + drmsurfalloc.flags =3D swap_pattern | (width_bytes / 8) |= depth_pattern; > + else > + drmsurfalloc.flags =3D swap_pattern | (width_bytes / 16) = | depth_pattern; > + > retvalue =3D drmCommandWrite(info->drmFD, DRM_RADEON_SURF_ALL= OC, > &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) >=20 I can apply those to cvs tonight. > Please note that I havent tested this with current xorg cvs because of va= rious inconveniences. > What about the 2560 limit? > I noticed that with the new RADEONDoAdjustFrame I can have 1280x1024-1280= x1024 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 >=20 > > Pageflipping won't work for r300 until the sarea and drm are updated > > to handle the additional xytiling regs. >=20 > I fixed couple of things with it and it should now work. > Its not very stable at least with tiling enabled(havent tested without) t= hough im afraid. >=20 > -- > Aapo Tahkola > |