I think we should forbid recursive maps of the same buffer. Direct3D10 also forbids them:
http://msdn.microsoft.com/en-us/library/ee418691(VS.85).aspx This has however some implications for draw module and the way state trackers setup vertex buffers: either we force state trackers to never pass the same buffer twice in set_vertex_buffers, or the draw module has to check this and map the buffer only once. Also, pipe_screen::buffer_map_range should be modified to return the pointer to the range, like the GL extension. Jose On Mon, 2010-01-18 at 15:56 -0800, Luca Barbieri wrote: > What are the Gallium semantics for nested buffer maps and unmaps? > > The current situation seems the following: > - Nouveau doesn't support nested mapping. It fully supports them with > a patch to libdrm I posted. > - r300 fully supports nested mapping > - VMware supports nested mapping, but only the outermost map can be > for writing (strange...) > - In OpenGL, nested mapping is disallowed > > Those who support nested maps do it by using a map counter. > > All drivers seem to ignore the range and just map the whole buffer. > Note that nesting with map_range would require to keep a LIFO stack of > mappings in the driver since unmap does not take the address as a > parameter. > > What does the Gallium interface specify, or what do we want it to be? > > It seems that whatever is chosen as the interface, some drivers will > need to be fixed. > > I see two possible avenues: > 1. Ban nested mapping. This is somewhat uncomfortable for those who > need to map multiple buffers at once, which may or may not be the same > one. > 2. Fully allow nested mapping, even with unpaired map/unmap, but add > an address parameter to unmap. Drivers are required to reuse the same > mapping for non-range maps, but may not do so for map_range. In that > case, they can check whether the address being unmapped is the "whole > buffer" mapping and if so lower the map count, and otherwise directly > call munmap or the equivalent. > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
