<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 12, 2017 at 2:47 AM, Juan A. Suarez Romero <span dir="ltr"><<a href="mailto:jasuarez@igalia.com" target="_blank">jasuarez@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Reviewed-by: Juan A. Suarez Romero <<a href="mailto:jasuarez@igalia.com">jasuarez@igalia.com</a>><br><div class="HOEnZb"><div class="h5"></div></div></blockquote><div><br></div><div>Is this patch sufficient to fix the bug you were seeing yesterday?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
On Tue, 2017-04-11 at 11:11 -0700, Jason Ekstrand wrote:<br>
> v2 (Jason Ekstrand):<br>
>  - Limit to 2GB instead of 4GB<br>
><br>
> v3 (Jason Ekstrand):<br>
>  - Fix the build by using pAllocateInfo instead of pAllocationInfo (not<br>
>    sure how that happened).<br>
>  - Return vK_ERROR_OUT_OF_DEVICE_MEMORY (Thanks Ilia!)<br>
><br>
> Cc: "Juan A. Suárez" <<a href="mailto:jasuarez@igalia.com">jasuarez@igalia.com</a>><br>
> ---<br>
>  src/intel/vulkan/anv_device.c | 20 ++++++++++++++++++++<br>
>  1 file changed, 20 insertions(+)<br>
><br>
> diff --git a/src/intel/vulkan/anv_device.<wbr>c b/src/intel/vulkan/anv_device.<wbr>c<br>
> index 35ef4c4..ee9c48f 100644<br>
> --- a/src/intel/vulkan/anv_device.<wbr>c<br>
> +++ b/src/intel/vulkan/anv_device.<wbr>c<br>
> @@ -1539,6 +1539,26 @@ 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 32 bits.  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>
> +    * We don't use vk_error here because it's not an error so much as an<br>
> +    * indication to the application that the allocation is too large.<br>
> +    */<br>
> +   if (pAllocateInfo->allocationSize > (1ull << 31))<br>
> +      return VK_ERROR_OUT_OF_DEVICE_MEMORY;<br>
> +<br>
>     /* FINISHME: Fail if allocation request exceeds heap size. */<br>
><br>
>     mem = vk_alloc2(&device->alloc, pAllocator, sizeof(*mem), 8,<br>
</div></div></blockquote></div><br></div></div>