Quoting Boris Brezillon (2017-09-27 15:06:53) > 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.
Hmm, you don't treat purging as permanent. But you do track the lose of contents, so retained is false? I took a harder line, and said that userspace should recreate the object from scratch after it was purged. I thought that would be easier overall. But maybe not.:) -Chris _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
