On Fri, 2014-06-20 at 13:50 -0400, Tom Stellard wrote: > On Wed, Jun 18, 2014 at 05:01:50PM +0200, Bruno Jiménez wrote: > > Hi, > > > > This is my second attempt to fix the mapping bug adding all the > > suggestions that Tom Stellard sent, and, so far, it seems that > > it is resolved. > > > > This series changes completely how OpenCL buffers are handled > > by the r600g driver. Before this, we would add them directly to > > a pool, and this pool would grow whenever we needed more space. > > But this process implied destroying the pool and creating a new > > one. There could be cases where a buffer would be mapped and > > the pool would grow, leaving one side of the mapping pointed > > to where the item was. This is the 'mapping bug' > > > > Now, Items will have an intermediate resource, where all mappings > > can be done, and when a buffer is going to be used with a kernel > > it is promoted to the pool. In the case where a promoted item > > is going to be mapped, it is previously demoted, so even if > > the pool changes its location due to growing, the map remains > > valid. In the case of a buffer mapped for reading, and used > > by a kernel to read from it, we will duplicate this buffer, > > having the intermediate buffer, where the user has its map, and > > an item in the pool, which is the one that the kernel is going > > to use. > > > > I've just pushed patches 1-9. Nice work!
Thanks! And thanks to you for all the help! Bruno > > -Tom > > > As a summary for v2: > > Patches 1-8: These are the main part of the series, and solve > > the mapping bug. > > Patches 1 and 7 now use less explicit castings > > Patch 2 is new and introduces the 'is_item_in_pool' > > function, which is used in patches 3 and 8 > > > > Patch 9: Is a complete rewrite of v1 patch 8 using gallium > > utils for double lists > > > > Patches 10 and 11: These are just a proof of concept for avoiding > > transfers GPU <-> GPU when using all CL Read/Write functions. > > They are v1 patch 9 splited in two to separate r600g changes > > from clover changes. > > Now, in clover's side it introduces and uses > > 'CLOVER_TRANSFER_MAP_DIRECTLY' so it doesen't collide with > > any other OpenCL flag. > > > > Please review and Thanks :) > > > > Bruno Jiménez (11): > > r600g/compute: Add an intermediate resource for OpenCL buffers > > r600g/compute: Add an util function to know if an item is in the pool > > r600g/compute: Add statuses to the compute_memory_items > > r600g/compute: divide the item list in two > > r600g/compute: Only move to the pool the buffers marked for promoting > > r600g/compute: Avoid problems when promoting items mapped for reading > > r600g/compute: Implement compute_memory_demote_item > > r600g/compute: Map only against intermediate buffers > > r600g/compute: Use gallium util functions for double lists > > r600g/compute: Map directly the pool in some cases > > clover: Use PIPE_TRANSFER_MAP_DIRECTLY when writing/reading buffers > > > > src/gallium/drivers/r600/compute_memory_pool.c | 294 > > ++++++++++++--------- > > src/gallium/drivers/r600/compute_memory_pool.h | 31 ++- > > src/gallium/drivers/r600/evergreen_compute.c | 38 ++- > > src/gallium/state_trackers/clover/api/transfer.cpp | 4 +- > > src/gallium/state_trackers/clover/core/object.hpp | 4 + > > .../state_trackers/clover/core/resource.cpp | 2 + > > 6 files changed, 233 insertions(+), 140 deletions(-) > > > > -- > > 2.0.0 > > > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev