[Mesa-dev] [PATCH 00/11] [RFC v2] Solve the mapping bug

Bruno Jimenez 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!

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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev




More information about the mesa-dev mailing list