On Mon, Feb 8, 2010 at 10:24 PM, Luca Barbieri <luca.barbi...@gmail.com> wrote: >> By making transfers context-private and non-shareable, it becomes >> possible for a driver to implement interleaved drawing and dma-uploads >> within a single command buffer. > > While we do this, how about removing transfer map and unmap functions > and making the create and destroy functions do mapping and unmapping? > > Since the transfer contents are flushed on destroy, anything other > than calling map just after create and unmap just before destroy does > not offer any benefit, so we may as well merge the functionality. > > Another option would be to flush on unmap and let transfer objects be > permanent, but I think this would complicate both state trackers and > drivers for a very dubious performance improvement.
Map/unmap make it all the way to the user's program, and there will likely be cases where user code maps/unmaps a buffer multiple times before drawing. The current transfer semantics can handle that with zero-copy if the state tracker does the right thing with it. If performance matters transfer creation can be made cheaper by not malloc'ing. Transfers aren't refcounted anyway so I don't see much of a benefit in forcing them to be dynamically allocated. ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
