On Don, 2012-01-26 at 20:45 +0100, Marek Olšák wrote: > On Tue, Jan 10, 2012 at 6:20 PM, Jose Fonseca <jfons...@vmware.com> wrote: > >> On Tue, Jan 10, 2012 at 5:15 PM, Jose Fonseca <jfons...@vmware.com> > >> wrote: > >> > > >> > Also, please provide app name and performance figures w/ this > >> > change. > >> > >> OK. Torcs, the Forza track at the start. > >> > >> With u_upload_unmap before drawing: > >> 21.4 - 22.1 fps > >> > >> Without u_upload_unmap: > >> 22.7 - 23.1 fps > > > > > >> The improvement is approximately 1.1 fps, which is probably too > >> little > >> for other people to care, but why throw it away? > > > > This is roughly 5%. It is still significant. > > > > But it surprises me it is so high. > > > > Perhaps we should have a couple of fast entrypoints for transfering to/from > > buffers without the overhead of creating transfer objects. > > Okay so the plan is to keep refactoring the transfer API until the > overhead disappears? Sounds good. > > I propose these changes: > 1) Merge get_transfer with transfer_map. > 2) Merge transfer_unmap with transfer_destroy.
AFAIR everybody agreed a while ago this should be done. > 3) Make the pipe_transfer struct fully opaque, but then there must be > another way to return the strides of mapped textures (out parameters > of transfer_map?). Think of this as decoupling driver-private transfer > objects from ordinary return values like the strides. > 4) The drivers which don't need transfer objects (e.g. non-texture > transfers) can return a NULL pipe_transfer struct, making transfer > objects fully optional. Only the returned pointer into the resource > determines whether transfer_map has been successful. > > (1) and (2) should help reduce the call overhead. (3) is a preparation > for (4). (4) should help kill all the code required to allocate, > initialize, and free the pipe_transfer struct when it's needed by > neither a driver nor a state tracker. Sounds good to me. Something else that might be useful at some point would be another entrypoint which passes in a pointer to the data to be transferred. This could allow saving a CPU copy in cases where the state tracker already has the data in the form appropriate for the transfer. For drivers that can't take advantage of that, there could be a utility function which uses the get_transfer and transfer_destroy hooks. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
