On Wed, 27 Sep 2017 14:50:10 +0100
Chris Wilson <[email protected]> wrote:
> Quoting Boris Brezillon (2017-09-27 14:45:17)
> > static struct vc4_bo *
> > vc4_bo_from_cache(struct vc4_screen *screen, uint32_t size, const char
> > *name)
> > {
> > @@ -111,6 +121,11 @@ vc4_bo_from_cache(struct vc4_screen *screen, uint32_t
> > size, const char *name)
> > return NULL;
> > }
> >
> > + if (vc4_bo_purgeable(bo, false)) {
> > + mtx_unlock(&cache->lock);
> > + return NULL;
>
> So this would just mean that the bo was purged in the meantime. Why not
> just try to use the next one in the cache or allocate afresh?
No, this means the BO was purged and the kernel failed to allocate the
memory back. We don't care about the retained status here, because we
don't need to restore BO's content, that's why we're not checking
arg.retained in vc4_bo_purgeable(). Allocating a fresh BO is likely to
fail with the same ENOMEM error because both path use the CMA mem.
> Not sure
> how way allocation failures are handled up the stack, but anyway this is
> not necessarily -ENOMEM.
Right, we should try with all elements in the list to see if one
of them is still around or if the kernel manages to get some
memory back in the meantime.
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
