[Mesa-dev] [PATCH 0/5] [RFC] r600g/compute: Adding support for defragmenting compute_memory_pool

[Bruno Jimenez]

On Wed, 2014-07-23 at 10:33 -0400, Tom Stellard wrote:
> On Fri, Jul 18, 2014 at 01:09:03PM +0200, Bruno Jimenez wrote:
> > On Thu, 2014-07-17 at 22:56 -0400, Tom Stellard wrote:
> > > On Wed, Jul 16, 2014 at 11:12:42PM +0200, Bruno Jiménez wrote:
> > > > Hi,
> > > > 
> > > > This series finally adds support for defragmenting the pool for
> > > > OpenCL buffers in the r600g driver. It is mostly a rewritten of
> > > > the series that I wrote some months ago.
> > > > 
> > > > For defragmenting the pool I have thought of two different
> > > > possibilities:
> > > > 
> > > > - Creating a new pool and moving every item here in the correct
> > > >     position. This has the advantage of being very simple to
> > > >     implement and that it allows the pool to be grown at the
> > > >     same time. But it has a couple of problems, namely that it
> > > >     has a high memory peak usage (sum of current pool + new pool)
> > > >     and that in the case of having a pool not very fragmented you
> > > >     have to copy every item to its new place.
> > > > - Using the same pool by moving the items in it. This has the
> > > >     advantage of using less memory (sum of current pool + biggest
> > > >     item in it) and that it is easier to handle the case of
> > > >     only having few elements out of place. The disadvantages
> > > >     are that it doesn't allow growing the pool at the same time
> > > >     and that it may involve twice the number of item-copies in 
> > > >     the worst case.
> > > > 
> > > > I have chosen to implement the second option, but if you think
> > > > that it is better the first one I can rewrite the series for it.
> > > > (^_^)
> > > > 
> > > > The worst case I have mentioned is this: Imagine that you have
> > > > a series of items in which the first is, at least, 1 'unit'
> > > > smaller than the rest. You now free this item and create a new
> > > > one with the same size [why would anyone do this? I don't know]
> > > > For now, the defragmenter code is so dumb that it will move
> > > > every item to the front of the pool without trying first to
> > > > put this new item in the available space.
> > > > 
> > > > Hopefully situations like this won't be very common.
> > > > 
> > > > If you want me to explain any detail about any of the patches
> > > > just ask. And as said, if you prefer the first version of the
> > > > defragmenter, just ask. [In fact, after having written this,
> > > > I may add it for the case grow+defrag]
> > > > 
> > > > Also, no regressions found in piglit.
> > > > 
> > > > Thanks in advance!
> > > > Bruno
> > > > 
> > > > Bruno Jiménez (5):
> > > >   r600g/compute: Add a function for moving items in the pool
> > > >   r600g/compute: Add a function for defragmenting the pool
> > > >   r600g/compute: Defrag the pool if it's necesary
> > > >   r600g/compute: Quick exit if there's nothing to add to the pool
> > > >   r600g/compute: Remove unneeded code from compute_memory_promote_item
> > > > 
> > > >  src/gallium/drivers/r600/compute_memory_pool.c | 196 ++++++++++++++++++-------
> > > >  src/gallium/drivers/r600/compute_memory_pool.h |  13 +-
> > > >  2 files changed, 156 insertions(+), 53 deletions(-)
> > > 
> > > Hi,
> > > 
> > > A took a brief look at these patches and they look pretty good.  I will
> > > look at them again tomorrow and then commit if I don't see any issues.
> > 
> 
> I've pushed these patches, thanks!
> 
> -Tom

Hi,

Thanks!
Bruno

> 
> > Hi,
> > 
> > Thanks, if you have any doubt about any of the patches just ask.
> > 
> > I have just ended writing a follow up series for doing grow + defrag at
> > the same time. I still have to test it, but if no problems arise I'll
> > send it to the list as soon as possible.
> > 
> > This new series is based on the patch that I sent here:
> > http://lists.freedesktop.org/archives/mesa-dev/2014-July/062923.html 
> > If you think it's good, could you push it to master?
> > 
> > Thanks in advance!
> > Bruno
> > 
> > > -Tom
> > > 
> > > > 
> > > > -- 
> > > > 2.0.1
> > > > 
> > > > _______________________________________________
> > > > mesa-dev mailing list
> > > > mesa-dev at lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> >