Skip to content

anv: don't unmap AUX ranges at BO delete

What does this MR do and why?

anv: don't unmap AUX ranges at BO delete

It is possible to free memory backing images before images are destroyed :

VkFreeMemory:

"Memory can be freed whilst still bound to resources, but those resources must not be used afterwards."

The spec leaves us the option to keep a reference on the associated memory and free it only when all the bound resources have been destroyed. Here we choose to free memory immediately.

One particular test in the CTS (dEQP-VK.synchronization.internally_synchronized_objects.pipeline_cache_graphics) does the following :

   imgA = vkCreateImage()
   imgB = vkCreateImage()
   memA = vkAllocateMemory()
   vkBindImageMemory(imgA, memA) # Aux mapping with ref count = 1
   vkFreeMemory(memA)            # Aux mapping removed, ref count = 0
   memB = vkAllocateMemory()     # Same address as memA
   vkBindImageMemory(imgB, memB)
   vkDestroyImage(imgA)	         # Removes the mapping of imgB-memB

   vkQueueSubmit()               # hang with pagefault in AUX-TT

The solution implemented in this change is to not do anything AUX-TT related in vkFreeMemory(). This soluation has some consequences, because a virtual memory address range freed and reallocated cannot be rebound in the AUX-TT until all the associated resources have released their AUX-TT mapping (to bring back the AUX-TT refcount of the range to 0). This should still be better than keeping the memory allocated through refcounting of the anv_bo.

Signed-off-by: Lionel Landwerlin lionel.g.landwerlin@intel.com Fixes: 7b87e1af ("anv: track & unbind image aux-tt binding") #10528 (closed)

Merge request reports