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

[Marek Olšák]

One thing to note here. Some Gallium modules already work even if the
returned transfer object is NULL. The drivers where transfer_unmap for
PIPE_BUFFER is actually no-op would benefit from this by skipping the
allocation of pipe_transfer entirely. It's not recommended to use such
a hack now, but it's the direction I'm heading for. The idea is if the
resource storage can be mapped directly, we shouldn't need to return
anything except for the texture strides.

Marek

On Wed, Oct 10, 2012 at 3:04 AM, 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.
>
> I get that I won't get a review of the whole patch, but at least an
> ack would be appreciated. :)
>
> Marek