On Tue, Jan 12, 2010 at 7:31 PM, Keith Whitwell <kei...@vmware.com> wrote: > On Mon, 2010-01-11 at 22:30 -0800, Luca Barbieri wrote: >> > I left out depth/stencil attachment because I could not think of a good >> > reason >> > for it. Do you have an example that it is better to ask the display >> > server for >> > a depth/stencil buffer than asking the pipe driver? >> I'm not sure about this. I mostly added it just because the old driver >> stack asks DRI2 for it. >> On second thought, it may be better to do it with the pipe driver. >> This would prevent sharing the depth buffer with other application, >> but I don't think any compositor/application uses this. > Theoretically an application could create a direct and indirect context > targetting the same window. Under those circumstances, there should be > only a single depth buffer shared between the contexts. I guess I will leave out depth/stencil attachment for now. The interface does not imply direct or indirect rendering, but all native displays use direct rendering right now. It should be easy to add depth/stencil attachment if there is a new native display that needs it. (Actually, in my early work, there was a depth/stencil attachment. It was removed and there is a comment saying that only color attachments are included intentionally.) > There are other ways to achieve the same result, basically sharing a > depth buffer between processes.
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
