> 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.
OpenGL does not allow you to map textures and when other APIs exposes map/unmap, I think the API unmap is always supposed to actually change the texture (this is also the case for OpenGL mapping of buffers), which transfer unmap does not do, since it is done by destroy. Thus, API map must be implemented with transfer create+map and API unmap must be implemented with transfer unmap+destroy, defeating the purpose of having them separate. If the API says otherwise, with merged functions, you can just remove the calls to map/unmap and have equivalent behavior. Basically the only thing you lose is the ability to unmap and then remap the transfer while using it. On many drivers this is a no-op, and where it actually does a munmap and mmap, you just decrease performance for no significant benefits. In fact, I think in the whole Mesa/Gallium codebase, get_tex_transfer is always immediately followed by transfer_map, and likewise for unmap and destroy. > 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 problem is that usually you have driver specific data after pipe_transfer, so the size is not known by the state tracker. A possible improvement could be to add a "private" pointer to pipe_transfer and make it a structure allocated by the caller and passed by reference to transfer_create. Then, drivers implementing transfers by just giving a pointer to the texture do not need private data, and others need to allocate the temporary buffer anyway, and the private transfer structure allocation is cheap compared to that. Basically pipe_transfer would become a "cookie" returned by create+map for use by unmap+destroy to flush the temporary buffer, if present. ------------------------------------------------------------------------------ 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
