[Mesa-dev] [PATCH] anv/allocator: Improve block pool growing asserts

Jason Ekstrand jason at jlekstrand.net
Thu May 4 14:27:20 UTC 2017


On Thu, May 4, 2017 at 1:17 AM, Juan A. Suarez Romero <jasuarez at igalia.com>
wrote:

> On Wed, 2017-05-03 at 09:44 -0700, Jason Ekstrand wrote:
> > ---
> >  src/intel/vulkan/anv_allocator.c | 11 +++++------
> >  1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_
> allocator.c
> > index d7b86c8..40913ec 100644
> > --- a/src/intel/vulkan/anv_allocator.c
> > +++ b/src/intel/vulkan/anv_allocator.c
> > @@ -338,6 +338,11 @@ anv_block_pool_expand_range(struct anv_block_pool
> *pool,
> >     assert(center_bo_offset >= pool->back_state.end);
> >     assert(size - center_bo_offset >= pool->state.end);
> >
> > +   /* Assert that we don't go outside the bounds of the memfd */
> > +   assert(center_bo_offset <= BLOCK_POOL_MEMFD_CENTER);
> > +   assert(size - center_bo_offset <=
> > +          BLOCK_POOL_MEMFD_SIZE - BLOCK_POOL_MEMFD_CENTER);
> > +
>
> Some lines below, we change the value of size and center_bo_offset.
> Shouldn't we put those assertions afterwards?
>

No, in block_pool_expand_range, these are never changed.  At least, if they
are, I don't see the change.


>         J.A.
>
> >     cleanup = u_vector_add(&pool->mmap_cleanups);
> >     if (!cleanup)
> >        return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
> > @@ -493,12 +498,6 @@ anv_block_pool_grow(struct anv_block_pool *pool,
> struct anv_block_state *state)
> >
> >     assert(size > pool->bo.size);
> >
> > -   /* We can't have a block pool bigger than 1GB because we use signed
> > -    * 32-bit offsets in the free list and we don't want overflow.  We
> > -    * should never need a block pool bigger than 1GB anyway.
> > -    */
> > -   assert(size <= (1u << 31));
> > -
> >     /* We compute a new center_bo_offset such that, when we double the
> size
> >      * of the pool, we maintain the ratio of how much is used by each
> side.
> >      * This way things should remain more-or-less balanced.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170504/d339e6ea/attachment.html>


More information about the mesa-dev mailing list