On Tue, Feb 9, 2010 at 8:34 AM, Luca Barbieri <luca.barbi...@gmail.com> wrote: >> Instead of combining create/map and >> unmap/destroy it would be better to make map more powerful. > > If I understand correctly, you are proposing to add a subrectangle > parameter to map/unmap, so that you can collect multiple rectangle > updates in a single upload happening at transfer destruction time. > > This is interesting: I think a better effect can be obtained by > merging the functions as described and also adding a > "validate_subrect" and "flush_subrect" ranges that would respectively > read back and upload a transfer subrectangle to/from the GPU object > (and of course, destruction would no longer implicitly flush and > creation no longer implicitly validate unless possibly told to so with > a specific flag). > >> At map/unmap time if you know the >> subset of data being read/written you can optimize the amount of data >> being transferred, especially in the write-only case where you can >> keep track of the dirty ranges and possibly combine them to fewer >> uploads. If you combine create+map and unmap+destroy you end up >> limiting yourself for no reason other than minor convenience. > > I think adding an explicit validate_subrect and flush_subrect allows > to do this, and is actually better since it also allows efficient > implementation of glFlushMappedBufferRange. > > However, I'm not sure whether, in the OpenGL case, this would be an > optimization and not a pessimization. >
I'm interested in exploring all of these options. My goal at this point is to make a first pass over the problem and fix the most significant architectural issues, specifically making transfers context-private, unifying the gpu-side aspects of buffers and textures, etc. Once that's done, looking at the details of how we're doing transfers, and indeed what a transfer really is, is completely feasible. One option would be to say that a transfer is really just an abstraction of piece of AGP/DMA memory, and that up/downloads from specific gpu-side entities can be made by copy-to/from-transfer commands. Another might be to say that transfers turn into something like DX staging resources, with internal structure like width, height, mipmaps etc, which can be mapped by the CPU but never bound to the GPU, and again copy-to/from-staging-resource commands mediate the up/downloads. Yet a third would be to drop the transfer map/unmap commands and make their lifetime explicitly limited to a single up/download. Once the current round of changes is done, it may be easier to see what the best path forwards is. Keith Keith ------------------------------------------------------------------------------ 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
