[Mesa-dev] [PATCH] gallium: unify transfer functions
stephane.marchesin at gmail.com
Thu Oct 11 15:01:26 PDT 2012
On Thu, Oct 11, 2012 at 3:00 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Thu, Oct 11, 2012 at 10:05 PM, Stéphane Marchesin
> <stephane.marchesin at gmail.com> wrote:
>> On Tue, Oct 9, 2012 at 6:04 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>> 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:
>>> 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:
>>> 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.
> No, we don't plan to get rid of map/unmap.
> You can skip the GPU->CPU copy in "map" if one of the
> PIPE_TRANSFER_DISCARD_* flags is set.
But as I said on irc, you can't skip the copy on unmap, so you do two
copies per texture upload.
More information about the mesa-dev