--- Adam K Kirchhoff <[EMAIL PROTECTED]> wrote: > Jacek Rosik wrote: > > >Hi, > > > >Dnia 28-01-2005, pią o godzinie 16:27 +0100, Roland Scheidegger > >napisał(a): > > > > > >>Jacek Rosik wrote: > >> > >> > >>>Hi, > >>> > >>>I have some questions about r200 depth tiling. Generally I'm also > >>>interested in r100 tiling too, but currently i work on r200. > >>> > >>>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 > >>>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? > >>> > >>> > >>> > >>> > >>Well, the span functions would indicate that. It doesn't quite match > the > >>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 > details. > >> > >> > > > >Thanks, I'll take a look at it. > > > > > > > >>>I don't quite follow third line before last? Can someone enlighten > >>>me? > >>> > >>> > >>You mean the pitch & 0x20 stuff? Yeah, looks strange. > >>Looking at it, it seems like it ensures that each "block line" starts > >>with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will > have > >>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. > > >>something like ensuring it's on a different memory channel or > different > >>bank or whatnot). > >> > >> > >Yeah, I thought something similar. > > > > > > > >>This is, btw, quite similarly strange to what Stephane needed on his > >>rv100 to get the correct pixel address for color tiling, this one also > > >>tinkered with that 11th bit (see RadeonDoAdjustFrame). > >> > >> > >> > >>>Generally if one could explain tiling a bit for me I would be > >>>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 > >>>this possible with shared depth buffer. This means that each 3D > >>>window would have different depthOffset but pointing to the same > >>>shared buffer. > >>> > >>> > >>I'm not sure if it's possible to do that with depthOffset (well > maybe). > >>There is however an interesting bit in RB3D_CNTL > >>(R200_DEPTH_XZ_OFFEST_ENABLE, I guess "XZ" is a typo, just as is > >>"OFFEST"?) and the corresponding (?) register > >>(R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly > >>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. > > > > > I somehow missed this discussion the first time, but thankfully Alex > pointed it out to me... > > Anyway... I've applied your patch, Jacek. It mostly works, but > definitely has some issues: > > http://68.44.156.246/glforestfire.png > http://68.44.156.246/glplanet.png > > This is what happens when I move the window to the lower right hand > corner on a MergedFB setup running at 2560x1024. > The OFFSETS get changed but then the output needs to be translated back into position. AMY ONE HAVE A FIX FOR THIS!!!!
Also you seam tobe getting something I did not get. In my attempts the img moved to the boarder of the window, so that the cutoff was allways at a window boundry. This could mean there are some math problems in the patch your using. > Adam > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
