From: Jacek R. <pa...@fa...> - 2005-01-29 09:00:07
|
Hi, Dnia 28-01-2005, pi=B1 o godzinie 16:27 +0100, Roland Scheidegger napisa=B3(a):=20 > Jacek Rosik wrote: > > Hi, > >=20 > > I have some questions about r200 depth tiling. Generally I'm also=20 > > interested in r100 tiling too, but currently i work on r200. > >=20 > > First of all in functions r200_mba_z16|32 from r200_span.c frontPitch > > offset is used. Is it intentional or just because depthOffset is=20 > > also the same? Maybe it should be depthOffset? > Yes, I think depthPitch (you surely meant that, yes?) instead of > frontPitch might be a good idea. I don't think there's a good reason to > use frontPitch there, even though currently they are always the same. Yes, I meant depthPitch. They are the same but only for resolutions where width is multiple of 32. Depth pitch is rounded to be multiple of 32. Hmm... I think that is wrong since tile size seems to depend on fb depth and probably tiles on r100 also have different sizes. So this is correct only for r200 with 32bpp fb depth. > > Depth tiles on r200 are 32x16 or 64x16, depending on FB depth, right? > >=20 > >=20 > Well, the span functions would indicate that. It doesn't quite match th= e > experiences made when implementing hyperz, however (where the same > number of tiles needed to be cleared regardless of 16 or 32bit z depth, > and tile size more seemed to correspond to 4x4 microtiles and 8x2 > macrotiles, thus a tile size of 32x8). I never really fully understood > that however, something just doesn't fit. See th drm clear code for det= ails. Thanks, I'll take a look at it. > > I don't quite follow third line before last? Can someone enlighten=20 > > me? > You mean the pitch & 0x20 stuff? Yeah, looks strange. > Looking at it, it seems like it ensures that each "block line" starts=20 > with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will hav= e=20 > set that (for x 0-31) to 0, y 16-31 to 1 and so on. > Seems to me like it might be related to how the ram is organized (e.g.=20 > something like ensuring it's on a different memory channel or different= =20 > bank or whatnot). Yeah, I thought something similar. > This is, btw, quite similarly strange to what Stephane needed on his=20 > rv100 to get the correct pixel address for color tiling, this one also=20 > tinkered with that 11th bit (see RadeonDoAdjustFrame). >=20 > > Generally if one could explain tiling a bit for me I would be=20 > > grateful. What I'm trying to do is to is to modify depthOffset to be > > as close to top-left corner of viewport as possible and modify. I=20 > > this possible with shared depth buffer. This means that each 3D=20 > > window would have different depthOffset but pointing to the same=20 > > shared buffer. > I'm not sure if it's possible to do that with depthOffset (well maybe).= =20 > There is however an interesting bit in RB3D_CNTL=20 > (R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is=20 > "OFFEST"?) and the corresponding (?) register=20 > (R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly=20 > invented for that... So this would mean that depth buffer can start at different x,y than color buffer? Can someone with the docs confirm that. Anyway I think I will experiment with it a little more and see what I'll get. Unfortunately I'll be quite busy in next weeks, but I hope I'll get back to it soon. BTW: I have working solution for color but I wonder if this will work with color tiling. Of course offset Would have to be aligned to the closest tile. Can You take a look at it? (It's missing some bits but generaly apps which don't use depth should work Unfortunately I don't think there are many ;). Attached is a patch. Any comments are welcome. Best, --=20 Jacek Rosik <pa...@fa...> |