On Tue, 2010-01-19 at 11:10 +0800, Chia-I Wu wrote: > On Tue, Jan 19, 2010 at 10:21 AM, Younes Manton <youne...@gmail.com> wrote: > > On Mon, Jan 18, 2010 at 9:10 PM, Chia-I Wu <olva...@gmail.com> wrote: > >> On Tue, Jan 19, 2010 at 7:58 AM, Luca Barbieri <l...@luca-barbieri.com> > >> wrote: > >>> The XImage backend keeps a transfer permanently and map/unmaps to do > >>> modifications. > >>> However, Gallium transfers can be implemented by making and keeping a > >>> copy of the surface, flushing it back on transfer destruction. > >>> Thus, it should be fixed to create and destroy a transfer every time > >>> it maps the surface. > >> Thanks, that should be an easy fix. > >> But I do wonder if a pipe transfer is always supposed to be temporary? Its > >> operations, transfer_map and transfer_unmap, kind of hinted me that the > >> pipe > >> transfer can be used repeatedly. > > It was my understanding that the transfer happened on destroy and that > > was how the nouveau implementations were written. You can probably > > find the original thread, IIRC it was Michael Danzer that did the > > interface and softpipe.
It's true that right now transfers are only expected to read data from the GPU at creation time and write data to the GPU at destruction time. As you guys discussed on IRC, at this point create/map and unmap/destroy could probably be combined into a single operation each, but there are more invasive changes to the transfer interfaces (making transfers context operations pipelined wrt other drawing operations, changing the data model to minimize copies) on the horizon, so it's probably not worth bothering without addressing those. That said: > The ximage backend uses only softpipe and that is why I didn't notice that. > softpipe seems to work well with permanent pipe transfers, but I think it is > vital to use the interface correctly. If the ximage backend is intrinsically tied to softpipe, it's kind of legitimiate for it to rely on softpipe specific transfer semantics if that gives a tangible benefit, e.g. by saving transfer creation/destruction overhead. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ 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
