Jacek Rosik wrote:

Hi

Dnia 29-01-2005, sob o godzinie 02:29 +0100, Stephane Marchesin
napisał(a):

Roland Scheidegger wrote:

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).
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).


Also, since Jacek is interested in depth tiling, I have to mention that on my rv100, the depth buffer is not tiled until you use hyperz.
Then when hyperz is used, the depth buffer becomes tiled. The depth tiling function is currently unknown (I still have to RE it) but it doesn't seem to work if I use the r100 or r200 depth tiling functions as defined in {radeon,r200}_span.c.



Would 7000 PCI be a rv100? I think I have one somewhere. Without depth tiling my Idea should be simpler to implement.

Yes. But, I'd like to have hyperz enabled by default soon, so you'll probably have to deal with depth tiling on this card too.
Anyway it might be useful for some testing.



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...

Yes, AFAICT the same thing (private z buffers) should work on r100.

Now I think the real trouble with private z buffers is how these will interfere with hyperz...


Huh I thought that hyperz would be simpler with private z buffers. What about private z buffers and private back buffers. Since most applications render only to back that would make them as fullscreen applications. Wouldn't It be simpler to implement hyperz and color tiling then?

The trouble with hyperz is we're not quite sure how it works for the corner cases (for example I'm not sure if it's possible to have private depth buffers + hyperz).
Not to mention that private depth or back buffers are a real pain to add since you'd need a fb memory allocator.


Btw, you don't want a private back buffer because this would disable pageflip (which is way faster than the copy).

Stephane





-------------------------------------------------------
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