On Mon 03 Apr 2017, Jason Ekstrand wrote: > On Mon, Apr 3, 2017 at 3:45 PM, Chad Versace <chadvers...@chromium.org> wrote: > > On Mon 03 Apr 2017, Jason Ekstrand wrote: > > > On Mon, Apr 3, 2017 at 12:31 PM, Chad Versace <chadvers...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
