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.

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

Reply via email to