[Mesa-dev] [PATCH v3 07/18] anv/allocator: Add a BO cache
Chad Versace
chadversary at chromium.org
Tue Apr 4 18:07:06 UTC 2017
On Mon 03 Apr 2017, Jason Ekstrand wrote:
> On Mon, Apr 3, 2017 at 3:45 PM, Chad Versace <chadversary at chromium.org> wrote:
> > On Mon 03 Apr 2017, Jason Ekstrand wrote:
> > > On Mon, Apr 3, 2017 at 12:31 PM, Chad Versace <chadversary at chromium.org> wrote:
> > > > Since each VkDevice has a unique drm device fd, and since the kernel
> > > > allocates gem handles consecutively on the fd, and since struct
> > > > hash_table only grows and never shrinks, and since patch 8/18 inserts
> > > > every VkDeviceMemory into the cache... I believe no collisions are
> > > > possible in anv_bo_cache.
> > > >
> > >
> > > Does this fall under the category of unbreakable kernel ABI or is it
> > > just a
> > > side-effect of the implementation? If not, then I'm reluctant to trust
> > > it.
> >
> > I'm not certain. But krh, sitting beside me, says "It's ABI at this point.
> > The kernel uses a 'idr' structure which guarantees that behavior".
> >
>
> If we think we can rely on it, I'm happy to make it into a flat array but
> it'll basically be a simplified hash table at that point.
Whatever you want. We've discussed the trade-offs of each, and the
difference isn't too big, so I'm ok with either.
More information about the mesa-dev
mailing list