----- Original Message ----- > On Tue, Jan 10, 2012 at 12:29 PM, Jose Fonseca <jfons...@vmware.com> > wrote: > > Still catching up on email traffic during holidays... > > > > I agree that user buffer uploads should be moved out of drivers, > > but I don't think this is the way to go. > > > > This "PIPE_TRANSFER_MAP_PERMANENTLY" means the driver relinquishes > > the ability to transform this data in any way before reashing the > > GPU -- i.e., prevents any sort of workarounds -- something can't > > be always guaranteed. Flushing with map helps is also > > non-portable. > > The flag is optional, it doesn't have to implemented by everybody. If > we do the uploads in the state tracker, we will also do any required > data transformation so that drivers don't have to do it at all.
The same can be said for everything. I don't object adding yet another code path specific to a subset of hardware, provided the benefits justify its existence. But honestly I'm not yet convinced of this, as there was no attempt to backup with solid arguments why this matters. Furthermore this violates one of the principles gallium (and all 3D apis) have of unmapping all resources when drawing. > > It looks to me that state trackers and/or drivers are not properly > > using PIPE_USAGE_STREAM flag. As all cases where > > PIPE_TRANSFER_MAP_PERMANENTLY would be used, the right way to do > > it would be for the state tracker to set PIPE_USAGE_STREAM, the > > pipe driver to recognize PIPE_USAGE_STREAM, and keep the mapping > > permanently internally, making mapping/unmapping of such buffers > > mere no-ops. > > We were doing that already and it wasn't good enough. Avoiding > create+map+unmap+destroy *calls* have brought higher frame rates in > apps with lots of draw operations. I understand the number map/unmap call is reduced. But how does this interface change affect in any way the number of create/destroy calls? Also, please provide app name and performance figures w/ this change. Jose PS: Keith Whitwell de-fact no longer is the Gallium's "Benevolent Dictator for Life", but we'll need to institute/enforce more due process with Gallium interface changes to ensure that gallium doesn't become something radically different from its vision & future requirements. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
