<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 4, 2017 at 1:59 AM, Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quoting Jason Ekstrand (2017-08-04 02:25:26)<br>
<span class="">> This is mostly a copy+paste of the BO cache but it's a bit simpler<br>
> because syncobjs don't have actual backing storage so we don't need to<br>
> check sizes or anything like that.  Also, we put the refcount directly<br>
> in anv_syncobj because they will always be heap pointers.<br>
<br>
</span>Ok, but why do we need one at all? Some part of the Vk spec, some bad<br>
behaviour you noticed? Or just that it is more elegant to be minimalist?<span class=""><br></span></blockquote><div><br></div><div>Gah!  I thought I saw a real-world problem and decided the kernel must be de-duplicating for me.  But now I remember that it doesn't and just looked at the kernel code and confirmed that it gives you a new idr entry on every fd_to_handle.  I'll delete all this garbage and go back to doing it the way I was before.  Thanks for pointing that out!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> ---<br>
>  src/intel/vulkan/anv_<wbr>allocator.c | 194 ++++++++++++++++++++++++++++++<wbr>+++++++++<br>
>  src/intel/vulkan/anv_device.c    |   9 +-<br>
>  src/intel/vulkan/anv_private.h   |  40 ++++++++<br>
>  3 files changed, 242 insertions(+), 1 deletion(-)<br>
><br>
> diff --git a/src/intel/vulkan/anv_<wbr>allocator.c b/src/intel/vulkan/anv_<wbr>allocator.c<br>
> index efaaebc..204c466 100644<br>
> --- a/src/intel/vulkan/anv_<wbr>allocator.c<br>
> +++ b/src/intel/vulkan/anv_<wbr>allocator.c<br>
> @@ -1422,3 +1422,197 @@ anv_bo_cache_release(struct anv_device *device,<br>
><br>
>     vk_free(&device->alloc, bo);<br>
>  }<br>
> +<br>
> +VkResult<br>
> +anv_syncobj_cache_init(struct anv_syncobj_cache *cache)<br>
> +{<br>
> +   cache->map = _mesa_hash_table_create(NULL, _mesa_hash_pointer,<br>
> +                                        _mesa_key_pointer_equal);<br>
<br>
</span>Not hash_uint for u32? Bah, for the number of ht mesa creates for<br>
looking up u32 names, you would think it would have an ultra-specialised<br>
data struct for it. :(<br>
<span class="HOEnZb"><font color="#888888">-Chris<br>
</font></span></blockquote></div><br></div></div>