On Thu, Oct 11, 2012 at 3:00 PM, Marek Olšák <mar...@gmail.com> wrote: > On Thu, Oct 11, 2012 at 10:05 PM, Stéphane Marchesin > <stephane.marche...@gmail.com> wrote: >> On Tue, Oct 9, 2012 at 6:04 PM, Marek Olšák <mar...@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. > > 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. Stéphane _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
