[Mesa-dev] [PATCH 00/11] [RFC v2] Solve the mapping bug
brunojimen at gmail.com
Fri Jun 20 11:04:41 PDT 2014
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!
And thanks to you for all the help!
> > 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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev