On Thu, 2017-05-04 at 07:27 -0700, Jason Ekstrand wrote: > On Thu, May 4, 2017 at 1:17 AM, Juan A. Suarez Romero <jasua...@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. >
d'oh! You're right. I was reading in the grow function, which is just after the expand_range :) Then, Reviewed-by: Juan A. Suarez Romero <jasua...@igalia.com> > > 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@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
