[Mesa-dev] [PATCH] gallium: unify transfer functions

Stéphane Marchesin stephane.marchesin at gmail.com
Thu Oct 11 13:05:54 PDT 2012

On Tue, Oct 9, 2012 at 6:04 PM, Marek Olšák <maraeo at gmail.com> wrote:
> Hi,
> this is actually a very small cleanup that got unexpectedly big. I
> really underestimated the size of gallium.
> It's part of the plan discussed here:
> http://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg17930.html
> The idea is that get_transfer+transfer_map is folded into
> transfer_map, and transfer_unmap+transfer_destroy is folded into
> transfer_unmap. transfer_map must create and return the transfer
> object and transfer_unmap must destroy it. transfer_map is successful
> if the returned buffer pointer is not NULL. If transfer_map fails, the
> pointer to the transfer object remains unchanged (i.e. doesn't have to
> be NULL).
> I couldn't send the patch to mesa-dev, because it's too big. It's here:
> http://cgit.freedesktop.org/~mareko/mesa/commit/?h=transfer&id=7a102748a1240c4b2624c6727b480078d2905012
> 103 files changed, 1204 insertions, 2014 deletions
> There are no piglit regressions on r600g, softpipe, and llvmpipe. I
> haven't tested the other drivers nor have I tested the state trackers
> not covered by piglit.

So is the long term goal to get rid of the map/unmap completely and
use inline_write instead? That could save a copy for texture uploads
in cases where map() is also a copy.


> I get that I won't get a review of the whole patch, but at least an
> ack would be appreciated. :)
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list