[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dri-devel
Subject:    Re: R200 depth tiling questions.
From:       Stephane Marchesin <marchesin () icps ! u-strasbg ! fr>
Date:       2005-01-31 15:34:13
Message-ID: 41FE4FF5.5030502 () icps ! u-strasbg ! fr
[Download RAW message or body]

Jacek Rosik wrote:
> Dnia 29-01-2005, sob o godzinie 21:38 +0100, Stephane Marchesin
> napisał(a):
> 
>>Jacek Rosik wrote:
>>
>>
>>>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.
> 
> 
> I hope there will be an option to disable color tiling?
> 

You mean depth tiling I think ?

There is no way to disable depth tiling on radeon, these cards have it 
all the time (except the rv100 which only has depth tiling when hyperz 
is used).

> 
> 
>>>>>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).
> 
> 
> I don't think this is argument against private backbuffers. Pageflipping
> only works with single client. We can still do pageflipping with single
> client with shared depth buffer and switch to private with more
> applications. Moreover we can detect fullscreen situation and do
> pageflipping even with private buffers too. 

Right, in any case there has to be a mechanism to enable/disable it. 
However, the fullscreen hooks are long dead.

> 
> Anyway private z buffers would be a first step towards privet buffers.
> Do You think It would be possible to allocate z buffers with current X
> memory manager as pixmaps of appropriate size? This would be a
> temporary, just to test such solution.

I think X can kick pixmaps out of video memory as it likes, so that 
might not be very reliable.

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

[prev in list] [next in list] [prev in thread] [next in thread]