<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 11, 2017 at 11:27 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"><span class="">On Tue, Apr 11, 2017 at 10:58:41AM -0700, Jason Ekstrand wrote:<br>
> Cc: "Juan A. Suárez" <<a href="mailto:jasuarez@igalia.com">jasuarez@igalia.com</a>><br>
> ---<br>
>  src/intel/vulkan/anv_device.c | 17 +++++++++++++++++<br>
>  1 file changed, 17 insertions(+)<br>
><br>
> diff --git a/src/intel/vulkan/anv_device.<wbr>c b/src/intel/vulkan/anv_device.<wbr>c<br>
> index 35ef4c4..b24c739 100644<br>
> --- a/src/intel/vulkan/anv_device.<wbr>c<br>
> +++ b/src/intel/vulkan/anv_device.<wbr>c<br>
> @@ -1539,6 +1539,23 @@ VkResult anv_AllocateMemory(<br>
>     assert(pAllocateInfo-><wbr>memoryTypeIndex == 0 ||<br>
>            (!device->info.has_llc && pAllocateInfo->memoryTypeIndex < 2));<br>
><br>
> +   /* The kernel relocation API has a limitation of a 32-bit delta value<br>
> +    * applied to the address before it is written which, in spite of it being<br>
> +    * unsigned, is treated as signed .  Because of the way that this maps to<br>
> +    * the Vulkan API, we cannot handle an offset into a buffer that does not<br>
> +    * fit into a signed 31 bits.<br>
<br>
</span>Correct. Other users take advantage of the negative deltas.<br>
<span class=""><br>
> The only mechanism we have for dealing with<br>
> +    * this at the moment is to limit all VkDeviceMemory objects to a maximum<br>
> +    * of 2GB each.  The Vulkan spec allows us to do this:<br>
> +    *<br>
> +    *    "Some platforms may have a limit on the maximum size of a single<br>
> +    *    allocation. For example, certain systems may fail to create<br>
> +    *    allocations with a size greater than or equal to 4GB. Such a limit is<br>
> +    *    implementation-dependent, and if such a failure occurs then the error<br>
> +    *    VK_ERROR_OUT_OF_DEVICE_MEMORY should be returned."<br>
> +    */<br>
> +   if (pAllocationInfo-><wbr>allocationSize > (1ull << 31))<br>
> +      return VK_ERROR_OUT_OF_HOST_MEMORY;<br>
<br>
</span>Hmm. So how do we lift this?</blockquote><div><br></div><div>Good question.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is this a complete blocker to large object<br>
support, or is this only the slab allocator that is limited? The<br>
phrasing (all VkDeviceMemory) suggests that this is imposing an absolute<br>
limit to any object size.<br></blockquote><div><br></div><div>That's correct.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Otoh, there are good reasons why you probably want to stitch together<br>
smaller objects to emulate a huge object (e.g. sparse).<br></blockquote><div><br></div><div>Yeah.  We don't support sparse yet but it would allow a user to create a texture that large.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If this is a blocker, there is enough space inside<br>
drm_i915_gem_relocation_entry to support a s65 (full u64 delta plus<br>
direction bit) by sacrificing read/write domain and reusing delta as a<br>
flag (with an exec flag to indicate the change in meaning). Or you may<br>
just declare this the final straw and all large objects will be<br>
softpinned and relocation-less.<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><br></div><div class="gmail_extra">That's my intended "final" solution.  On my medium-term todo list (probably later this year) is to pull a foreign memory allocator into mesa and just stop doing relocations altogether.  Once we can do that, this limitation is lifted.<br></div></div>